Wrapper for LibRaw

[jpsacha]

Wrapper for the LibRaw library. Current setup is for Windows 64, relies on the binary distribution of the LibRaw.

Help appreciated with adding support for MacOS and Linux.

[saudet]

Could you try to build it from source at least on Windows? We'll need to do that because it's using C++ and Visual Studio's runtime might very well break with the next release.

[jpsacha]

I added build from source for Windows and Linux. There will be one more commit with MacOS (hopefully will work similar to Linux)

[jpsacha]

The macOS build kind of works. Looks that JavaCPP (?) detects platform incorrectly on arm64. Passing flag -Djavacpp.platform=macosx-arm64 to mvn only works if running without cppbuild. cppbuild when run on command line on its own detects platform and build things correctly, so it is possible to build on arm64. Automated build may have problem with that.

[saudet]

Thanks! Let's add a .github/workflows/libraw.yml to get this tested. For macosx-arm64, we need to cross compile.
We can look at libffi for an example of how we can hack Autotools for that:
https://github.com/bytedeco/javacpp-presets/blob/master/libffi/cppbuild.sh#L86

[jpsacha]

Noticed that if I use JDK 18 I can build on macosx-arch64 without errors, but later when trying to use I am getting an error:

Exception in thread "main" java.lang.UnsatisfiedLinkError: no jniLibRaw in java.library.path: ...
...
Caused by: java.lang.UnsatisfiedLinkError: Can't load library: ~/.javacpp/cache/libraw-0.20.2-1.5.8-SNAPSHOT-macosx-arm64.jar/org/bytedeco/libraw/macosx-arm64/libjniLibRaw.dylib
...

I will check libffi

[jpsacha]

The setup in libffi is not trivial. Do not know which parts will need to be reused with libraw. I will leave MacOS alone. Will check tomorrow if I can use the preset on Linux. It does work on Windows - I can decode raw files.

[saudet]

I'm not talking about the whole presets for libffi, just the part to cross compile. We typically need to set environment variables like CC="clang -arch arm64" and CXX="clang++ -arch arm64" to cross compile on Mac with Autotools.

[jpsacha]

I added CC/CXX and a couple of other tweaks. Locally everything builds. In workflow, there is still some issue with maxosc-arch64: attempts to link x86_64. Linux, Windows, and macosx-x86_64 build up to creation of platform.

In local testing, using the sample code, I can decode images with Windows and macosx-x86_64 versions. macosx-x86_64 still has UnsatisfiedLinkError. Linux, at runtime, complains about: undefined symbol: GOMP_paralell.

[saudet]

For OpenMP, we need to "preload" the libraries, something like @Platform(value = "linux", preload = "gomp@.1"), which will also copy and bundle it. Mac probably needs some additional hacking for that as well...

In any case, your version numbers are not matching. You have "0.20.2" in some places and "3.4.2" in other places. You'll need to fix that first to be able to start testing builds with GitHub Actions.

[jpsacha]

preload = "gomp@.1" did not resolve the issue with libjniLibRaw.so: undefined symbol: GOMP_parallel on Linux. Following hint https://stackoverflow.com/a/50783188 , I added -fopenmp to javacpp compiler, using -Djavacpp.compilerOptions="-fopenmp" while building the preset on Linux by hand:

mvn -Djavacpp.compilerOptions="-fopenmp" install -projects .,libraw

How this can be added in presets so the automated build is using this too?

[saudet]

If you want to link statically with LibRaw, then we'll need to link using "link" instead of "preload", but it's a better idea to use dynamic/shared libraries anyway.

[jpsacha]

I am not clear what you mean in your comment. Without "-fopenmp" code builds but fails at runtime. Whatever "-fopenmp" does it makes the produced binaries useful in practice. Maybe there is another way, but it is not clear why we should not use "-fopenmp". Can you comment?

[saudet]

You shouldn't need to compile the JNI source code with -fopenmp, but anyway this is the kind of thing best left to build tools like CMake, because yes it gets complicated real quick. That can be done by building the native library into a dynamic/shared library, then we don't need to worry about those details. Are there any reasons why that's not possible or desirable for LibRaw?

[jpsacha]

I modified Linux cppbuild - it now works at runtime. I also added some examples of using LibRaw from Java and Scala to javacpp-examples on branch libraw_pr_examples: https://github.com/bytedeco/javacv-examples/tree/libraw_pr_example/LibRaw-demo They can be used to test the build.

At this point only macosx-arm64 fails at runtime as indicated above (#1211 (comment)). I tried different JVMs, setup similar to Linux, and coupe of other things. I do not see from the error what fails and how to fix it. Are there similar issues with other wrappers on macosx-arm64? Is this a JNI problem?

[saudet]

At this point only macosx-arm64 fails at runtime as indicated above (#1211 (comment)). I tried different JVMs, setup similar to Linux, and coupe of other things. I do not see from the error what fails and how to fix it. Are there similar issues with other wrappers on macosx-arm64? Is this a JNI problem?

Please set the "org.bytedeco.javacpp.logger.debug" system property to "true" to get more information on the console.

[saudet]

If you're fine without support for macosx-arm64, we can merge this. Sounds good?

[jpsacha]

Sounds good. Hopefully macosx-arm64 could be eventually added too.