bytedeco/javacpp-presets

HI @saudet : could javapp-pytorch support "torch::jit::export_onnx", it will make cpp -java-python pytorch model deploy all easy

java.lang.UnsatisfiedLinkError: no jniopencv_imgcodec in java.library.path Caused by: /usr/local/opt/libavif/lib/libavif.16.dylib (no such file) This affects both 4.13.0-1.5.13 and 4.14.0-1.5.14: opencv-4.14.0-1.5.14-macosx-x86_64.jar has a hard dependency from libopencv_imgcodecs.414.dylib to /usr/local/opt/libavif/lib/libavif.16.dylib This only affects the x86_64 version, arm64 seems to be clean. In contrast, 4.9.0-1.5.10 was fine. What should happen instead: libavif should be bundled and referenced from the jar.

This is the same as the issue #1797 that was happening in 13.3-9.24-1.5.14-SNAPSHOT, and that was solved in 13.3-9.24-1.5.14-SNAPSHOT. On Arch Linux, when convolution is required by ORT CUDA EP, it fails if the cudnn library is provided by the javacpp redist, and works well if the javacpp's redist dependency for cudnn is commented out, and provided by the system. I have the latest versions, as before, so it looks exactly as the bug that @saudet solved in the snapshot (I'm not sure how). It resurfaces in the release. I attach the JavaCPP debug logs here, and more details about how I experience this bug is provided in the linked issue (same code, updated dependencies from JavaCPP SNAPSHOT to release) javacpp.log

Hi @saudet Problem Description When iterating elements from ModuleListImpl via its iterator / .get() method, all returned objects are exposed as the base type org.bytedeco.pytorch.Module with full type erasure at the JNI boundary. Even though the underlying native module is our custom Scala layer (e.g. torchrec.basic.layers.MLP which extends Module), attempting to cast the returned Module reference back to the concrete subclass throws a hard ClassCastException. Exception Stack plaintext Exception in thread "main" java.lang.ClassCastException: class org.bytedeco.pytorch.Module cannot be cast to class torchrec.basic.layers.MLP (org.bytedeco.pytorch.Module and torchrec.basic.layers.MLP are in unnamed module of loader 'app') Root Cause Analysis ModuleListImpl JNI accessor only returns the generic base Module handle without retaining runtime subclass metadata of wrapped custom layers; All custom layers (MLP, CapsuleNetwork, CrossLayer etc.) inherit from Module, but JNI layer type informatio

private val sequential = new SequentialImpl() sequential.push_back(new DropoutImpl(dropout)) iceSupport] active device backend: cpu (requested=AUTO, cuda=false, mps=false, os=linux) # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007665b7153e37, pid=3256199, tid=3256200 # # JRE version: Java(TM) SE Runtime Environment Oracle GraalVM 25+37.1 (25.0+37) (build 25+37-LTS-jvmci-b01) # Java VM: Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 25+37.1 (25+37-LTS-jvmci-b01, mixed mode, sharing, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # C [libjnitorch.so+0x1753e37] torch::nn::AnyModuleHolder<torch::nn::DropoutImpl, at::Tensor>::forward(std::vector<torch::nn::AnyValue, std::allocator<torch::nn::AnyValue> >&&)+0x37 # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -F%F -- %E"