by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Samuel Audet
    @saudet
    Yes, and sure thanks!
    Brad Hards
    @bradh
    Now to find out if the changes I wanted in ffmpeg actually work in my app :-)
    Samuel Audet
    @saudet
    :+1:
    Brad Hards
    @bradh
    As it turns out, creating files crashes in the avcodec.c code somewhere. That looks like its going to be a pain to find and fix.
    Samuel Audet
    @saudet
    @retrogradeorbit BTW, it looks like "initialize at runtime" is now the default: https://medium.com/graalvm/updates-on-class-initialization-in-graalvm-native-image-generation-c61faca461f7
    Crispin Wellington
    @retrogradeorbit
    Im trying to perform an action on a QTextEdit changeEvent. This in C++ would be implemented via a protected method on a subclass changeEvent or via a textChanged signal being emitted.
    but I can't find any information on how to use signals and slots from javacpp
    Samuel Audet
    @saudet
    not sure about signals and slots, but protected methods can be implemented with Info.virtualize: https://github.com/bytedeco/javacpp/wiki/Mapping-Recipes#dealing-with-abstract-classes-and-virtual-methods
    Crispin Wellington
    @retrogradeorbit
    Hey I'm curious as to where javacpp gets its g++ -I flags from. When I use openjdk to run something like java -jar javacpp.jar Test.java -header, the command runs a Info: g++ -I/path/to/include ... That include path is correct. However when I run it using the graalvm jvm, it somehow ends up with the wrong -I path
    which java
    /home/crispin/graalvm-ce-java11-20.1.0/bin/java
    which javac
    /home/crispin/graalvm-ce-java11-20.1.0/bin/javac
    java -jar ~/.m2/repository/org/bytedeco/javacpp/1.5.3/javacpp-1.5.3.jar Mullion.java -header
    ...
    Info: g++ -I/home/crispin/graalvm-ce-java8-20.2.0-dev/include -I/home/crispin/graalvm-ce-java8-20.2.0-dev/include/linux ....
    somehow its using a different graalvm include path (I have a bunch of different graal distros in my homedir)
    Samuel Audet
    @saudet
    Right, that's something that's been fixed recently, see commit bytedeco/javacpp@13aa059
    BTW, all the config files for GraalVM Native Image are now getting bundled by default, see this sample: https://github.com/bytedeco/sample-projects/tree/master/opencv-stitching-native
    Crispin Wellington
    @retrogradeorbit
    fantastic
    Crispin Wellington
    @retrogradeorbit
    Awesome. Can confirm that works in latest javacpp master branch.
    Nick H
    @nicholashendrickx
    Hey @saudet I am trying to build against a method that has a std::vector<char> in the method signature ... i ran the against the info mapper and getting @Cast("char") @StdVector byte[] as the result. But then when i compile against the shared library I am getting no known conversion from ‘char’ to ‘signed char*’
    Samuel Audet
    @saudet
    You'll need something like @Cast({"signed char*", "std::vector<char>"}) @StdVector byte[] for this to work
    Nick H
    @nicholashendrickx
    ok, I am using @Cast({"signed char*", "std::vector<char>"}) @StdVector byte[] in java against std::vector<char> and getting no known conversion from ‘signed char*’ to ‘std::vector<char>::size_type {aka long unsigned int}’ now
    i tried building a vector<char> in the info mapper but i couldnt seem to get that to work properly
    Nick H
    @nicholashendrickx
    this is a vritual method too, i dont know if that makes a difference
    Nick H
    @nicholashendrickx
    im just slightly confused because i have another method that is @Cast("uint16_t*") @StdVector short[] and seems to work fine against std::vector<Uint16_t>
    Samuel Audet
    @saudet
    If that's a virtual method, it probably won't work with adapters like that. You'll probably need to map std::vector<char> itself
    Yes, @Cast("uint16_t*") works, but @Cast("uint16_t") would not
    Nick H
    @nicholashendrickx
    ok, i tried mapping it with infoMap.put(new Info("std::vector<char>").pointerTypes("CharVector").define()); but it didnt seem to like the class that was generated from it
    when i replaced @Cast({"signed char*", "std::vector<char>"}) @StdVector byte[] with CharVector
    Nick H
    @nicholashendrickx
    unless mapping it itself means something else?
    Samuel Audet
    @saudet
    That should work yes, what didn't it like?
    Brad Hards
    @bradh
    test_cc
    BEGIN /tmp/ffconf.xTy4tl3y/test.c
        1   int main(void){ return 0; }
    END /tmp/ffconf.xTy4tl3y/test.c
    gcc -m64 -I../include/ -c -o /tmp/ffconf.xTy4tl3y/test.o /tmp/ffconf.xTy4tl3y/test.c
    gcc -m64 -L../lib/ -Wl,-rpath,\$$ORIGIN/ -o /tmp/ffconf.xTy4tl3y/test /tmp/ffconf.xTy4tl3y/test.o -lstdc++ -lpthread -ldl -lz -lm -lva-drm -lva-x11 -lva
    /usr/bin/ld: cannot find -lva-drm
    /usr/bin/ld: cannot find -lva-x11
    /usr/bin/ld: cannot find -lva
    collect2: error: ld returned 1 exit status
    C compiler test failed.
    Clearly I can fix that by installing the missing library (libva-dev package in my case), but is that the right thing to do?
    Samuel Audet
    @saudet
    Yes, but ideally we should build it ourselves, it's just not done in cppbuild.sh, yet...
    Brad Hards
    @bradh
    Should I raise a ticket for that?
    Samuel Audet
    @saudet
    It's already there: bytedeco/javacv#1188
    Brad Hards
    @bradh
    Ah, different project.
    Samuel Audet
    @saudet
    Yeah, users open issues on repositories at random...
    Subsurfer
    @ErikGro

    Hi @saudet , i am trying to use javacpp with my roboVM project.
    Generating the gluecode (jnijavacpp.m, jniNativeLibrary.mm) and compiling all native code to a static library worked fine.
    But when trying to create objects from the generated java code the app crashes at runtime without stacktrace. Only following warnings occur:

    Warning: Could not load Loader: java.lang.UnsatisfiedLinkError: Couldn't load jnijavacpp from loader java.lang.PathClassLoader[<Main.app/lib/multiple jars>]: findLibrary returned null
    Warning: Could not load Pointer: java.lang.UnsatisfiedLinkError: Couldn't load jnijavacpp from loader java.lang.PathClassLoader[<Main.app/lib/multiple jars>]: findLibrary returned null
    com.erikgrodemo.demo.app: 99078

    Process finished with exit code 0

    Since the libraries are statically linked and dont need to be loaded at runtime i removed all “static { Loader.load(); }” from the generated code. Is this correct?
    I thought that jnijavacpp should be available since it is statically linked. Do you have any idea what i could be missing?

    Samuel Audet
    @saudet
    They still need to be initialized. Leave the Loader.load() calls, it will work fine.
    Also try to call System.loadLibrary("jnijavacpp") manually. If that works, and Loader.load() doesn't, then there's a bug in JavaCPP somewhere...
    Subsurfer
    @ErikGro

    The approach of loading the library mentioned in the README for RoboVM links the library statically.
    Static libraries are possible in roboVM since java code gets compiled to machinecode. The static library is linked at compile time with the executable.
    So my understanding of System.load is that it searches the library path and eventually calls jni_onload which is used to initializing javacpp.
    So System.load always crashes since there is no library on the library path.

    I found out that the native functions actually get called, but it crashes eventually because jni_onload and thus the initialization was never executed.

    Subsurfer
    @ErikGro

    Ok after some digging around, I found out I misunderstood system.load(). Even with static libraries it should call jni_onload_lib. But in a minimal demo project with roboVM i found out, that it seems like roboVM does not support the official jni standard, which states:
    “If a library L is statically linked, then upon the first invocation of System.loadLibrary("L") or equivalent API, a JNI_OnLoad_L function will be invoked with the same arguments and expected return value as specified for the JNI_OnLoad function.”

    You already mentioned it in your changelog from 2014: https://github.com/bytedeco/javacpp/blob/57574c2dafbc846b5cec2a968894424246a9e882/CHANGELOG.md#january-6-2014-version-07

    So if onload is not called i guess initializing manually the native code might be an option.

    wlfgang
    @wlfgang
    Is there a preferred/easy way to bundle a data file alongside a .so? I.e., the data file would be extracted to the same location as the .so under ~/.javacpp/cache?
    Samuel Audet
    @saudet
    @ErikGro I'm pretty sure recent versions of RoboVM support the "new" standard. Which version are you using?
    @wlfgang Yes, anything specified in @Platform(resource=...)will be bundled that way.
    Then we can use Loader.cacheResource() to have it extracted and cached.
    pawarashish564
    @pawarashish564
    Hello Everyone, You must have heard the Meme about Compiler that says "If Compiler knows there's missing semicolon on Line 16, then why don't it put one there ! " . I got one idea from the meme . I started developing a tool called "Autocompiler " which will automatically solve common java errors such as missing symbols and brackets. Its on Github if you'r interested Please do contribute . https://github.com/pawarashish564/AutoCompiler
    Samuel Audet
    @saudet
    @ErikGro To disable that feature though, we just need to reset the platform.library.static property: https://github.com/bytedeco/javacpp/blob/master/src/main/resources/org/bytedeco/javacpp/properties/ios-arm64.properties#L34
    Tuan Nguyen
    @tuan-nng
    hi, do you know where I can find the docs for mapping typedef ?
    Since this is a template instance though, what you need to do is actually this: https://github.com/bytedeco/javacpp/wiki/Mapping-Recipes#creating-instances-of-c-templates