search

clij / clij2-fft

21 stars 6 forks source link

Support? #1

Open haesleinhuepf opened 4 years ago

haesleinhuepf commented 4 years ago

Hey Brian @bnorthan ,

looks like you're working hard on making clij2-fft ready for shipping. I could imagine that this will become the most popular CLIJ2 function 😉 Can I help you with anything?

Cheers, Robert

bnorthan commented 4 years ago

Hi @haesleinhuepf when you get a chance maybe test to see if it runs on your end. Also we need to generate a MAC build and I believe you already did that for the old version.

By default the native build is enabled. To build in maven without the native build you need to do

mvn -Djavacpp.skip=true

If you want you can set javacpp .skip to true by default.

To build the native and java part run

javacppbuild.sh

The above requires you have a c++ development environment on your system though.

Let me know if it works for you and also if you have any suggestions on how to make the build process better.

haesleinhuepf commented 4 years ago

Hey Brian @bnorthan ,

wow, awesome, it built right out of the box on my mac:

haase@pcs-MacBook macosx-x86_64 % ls -l
total 2208
-rw-r--r--  1 haase  staff  986760 May 29 22:06 libclFFT.dylib
-rw-r--r--  1 haase  staff   34776 May 29 22:06 libclij2fft.so
-rwxr-xr-x  1 haase  staff   44732 May 29 22:06 libjniclij2fftWrapper.dylib
haase@pcs-MacBook macosx-x86_64 %

Shall I send these mac binaries as PR? We could collect them in the repository with the linux and windows files and package them together inside the jar?

Have a nice weekend and again: Awesome work!

Cheers, Robert

bnorthan commented 4 years ago

A pull request would be great. I made some minor changes so that the binaries are placed in platform specific directories, to avoid conflicts between the mac and linux version of libclij2fft.so. See the last 3 commits.

Also I need to specify the relative location of the binaries in the pom, it is done here, you may have to add in the mac path.

I tried to use javacpp.platform as they do in some of the javacpp presets but couldn't get it to work for some reason, so for now I am defining the platform specific link paths individually.

haesleinhuepf commented 4 years ago

Hey Brian @bnorthan ,

are there any news here on this project? I'm wondering what potential open tasks might be...

I just cloned it and ran this main method. An error message suggests that a clFFT library is missing:

Exception in thread "Run$_main" java.lang.UnsatisfiedLinkError: no jniclij2fftWrapper in java.library.path
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
    at java.lang.Runtime.loadLibrary0(Runtime.java:870)
    at java.lang.System.loadLibrary(System.java:1122)
    at org.bytedeco.javacpp.Loader.loadLibrary(Loader.java:1336)
    at org.bytedeco.javacpp.Loader.load(Loader.java:1077)
    at org.bytedeco.javacpp.Loader.load(Loader.java:947)
    at net.haesleinhuepf.clijx.plugins.clij2fftWrapper.<clinit>(clij2fftWrapper.java:28)
    at net.haesleinhuepf.clijx.plugins.OpenCLFFTUtility.runDecon(OpenCLFFTUtility.java:196)
    at net.haesleinhuepf.clijx.plugins.DeconvolveFFT.deconvolveFFT(DeconvolveFFT.java:44)
    at net.haesleinhuepf.clijx.plugins.DeconvolveFFT.main(DeconvolveFFT.java:166)
Caused by: java.lang.UnsatisfiedLinkError: no clFFT in java.library.path
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
    at java.lang.Runtime.loadLibrary0(Runtime.java:870)
    at java.lang.System.loadLibrary(System.java:1122)
    at org.bytedeco.javacpp.Loader.loadLibrary(Loader.java:1336)
    at org.bytedeco.javacpp.Loader.load(Loader.java:1033)
    ... 5 more

I'm new to multi-OS builds. Do you know which lib/so/dll files have to be located where in order to make this run smoothly?

Any hint is welcome!

Thanks!

Cheers, Robert

bnorthan commented 4 years ago

Hi @haesleinhuepf

Good question. Can you confirm that the correct version of clFFT for the operating system you are testing on was packed in the jar??

The code by the javacpp developers to actually load the library is actually quite complicated and can be found here

In the past I've built everything with the javacpp plugin and it puts the native libraries in a specific spot in the jar. At runtime it seems like they are always found.

A while ago you mentioned you don't have a c compiler on some of your machines, so you disabled the javacpp maven plugin and started placing the pre-built native libraries in resources. It seems to me that worked, but maybe it didn't and we just were fooled somehow.

Is it possible to backtrack to take a look at the old version that was based on ops-experiments, confirm if that works? And if so we can then figure out what is different.

bnorthan commented 4 years ago

Which operating system are you working with by the way?? Does it work on one but not another?

If it is finding jniclij2fftWraper but not clFFT, unzip the jar and examine the dependencies of jniclij2fftWrapper.

Here are some instructions on how to look at dependencies on each operating system.

haesleinhuepf commented 4 years ago

I just tested on Windows so far...

bnorthan commented 4 years ago

Did you copy the libraries to Fiji.app/lib ? It looks like the clij2 installer does that. If so did you use the same OS specific directory names I did? I re-organized the lib directory a bit in clij2-fft so libraries were put in OS specific locations. Maybe that is the issue. Fiji might expect a different naming convention.

bnorthan commented 4 years ago

Hi @haesleinhuepf I just ran a test and copied this directory to Fiji.app/lib.

It seems it can find the libraries after that. I even tried renaming windows-x86_64/lib to a nonsense name, and it still still found them.

However the naming of the subdirecties in 'Fiji.app/lib' could be important for Mac and Linux as they both use .so files. So the search order could be important. Let me know if you still have problems on Windows after copying the libraries to the lib directory. I will test on linux next.