Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support? #1

Open
haesleinhuepf opened this issue May 27, 2020 · 9 comments
Open

Support? #1

haesleinhuepf opened this issue May 27, 2020 · 9 comments

Comments

@haesleinhuepf
Copy link
Member

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
Copy link
Collaborator

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
Copy link
Member Author

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
Copy link
Collaborator

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
Copy link
Member Author

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
Copy link
Collaborator

bnorthan commented Jun 11, 2020

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
Copy link
Collaborator

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
Copy link
Member Author

I just tested on Windows so far...

@bnorthan
Copy link
Collaborator

bnorthan commented Jun 12, 2020

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
Copy link
Collaborator

bnorthan commented Jun 14, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants