AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
![]() I've tested this binary on my Apple Silicon M1 Mac. ~/dev/imagej-launcher > lipo -info ImageJ-macosxĪrchitectures in the fat file: ImageJ-macosx are: x86_64 arm64` The project compiled with no issue and the binary is universal: I also had some Java path issues, which may be a Big Sur thing. I made a fork () and tweaked CMakeLists.txt to provide the two arch for cmake (to make a universal binary). This is also supported by cmake, which I was pleased to see is used by the imagej-launcher. ![]() It does report an architecture mismatch error and does a fallback to system Java, which results in a 2nd Fiji icon in the dock-minor inconvenience.Īs noted in the thread, Apple docs show you can build for a different architecture than you run (can't test obviously) and can build universal binaries. Non-fat file: ImageJ-macosx is architecture: x86_64 Applications/Fiji.app/Contents/MacOS> lipo -info ImageJ-macosx The existing launcher actually works-despite being x86. ![]() (The normal Mac OS install also works fine in Rosetta, but is markedly slower.) I have Azul 11, but native OpenJDK is also available via homebrew, and use of the "No JRE" Fiji. So for Fiji/imagej the key is native JRE. … I've started a image.sc thread regarding getting things to work smoothly *native* rather than in Rosetta emulation.Įverything works when architectures are matched, so everything emulated or everything native. I've been using Fiji on an Apple Silicon M1 (arm64) MacBook Pro (Big Sur 11.4) Non-fat file: libclij2fft.dylib is architecture: arm64 Ld: warning: directory not found for option '-L/Users/haase/code/ops-experiments/ops-experiments-opencl/native'īut I'm not sure what I need to do next? I don't have a libjniclij2fftWrapper.dylibĮdit: I think it did work? The dylib does seem to be arm64 anyways. Linking CXX shared library libclij2fft.dylib Build files have been written to: /Users/piotrsobolewski/Dev/clij2-fft/native/clij2fft/cppbuild Then in 'clij2-fft/native' I ran which seemed to succeed: ![]() (I ran into an not obvious snag with a comment line, but got it resolved). Then I edited the second cppbuild.sh to replace the hard path to the path where clFFT is installed by homebrew (/opt/homebrew/opt/clfft/lib). I edited clij-fft/cppbuild.sh to account for arm64-to be consistent with cmake env variables. I really don't understand the structure with the two different cppbuild.sh.Īnyhow, I installed clFFT native arm64 for Big Sur from homebrew. I made a fork () and took a look at the scripts. So I thought instead of doing real work, I would try to contribute here and build it, as I had once done for JOCL. Applications/Fiji.app/lib/macosx/libjniclij2fftWrapper.dylib: mach-o, but wrong architecture `: : /Applications/Fiji.app/lib/macosx/libjniclij2fftWrapper.dylib: dlopen(/Applications/Fiji.app/lib/macosx/libjniclij2fftWrapper.dylib, 1): no suitable image found. Predictably, it failed to architecture mismatch: I tried running Ext.CLIJx_deconvolveRichardsonLucyFFT() on my MBP with Apple Sil … icon M1 (MacOS 11.4) So far I’ve also run into this issue when trying the CLIJ2 Richardson-Lucy deconvolution by and started an issue on CLIJ2-FFT: /clij/clij2-fft So my question to those more knowledgable and those writing plugins: what other libraries are like JOCL, that they need to be recompiled? I was able to do this-it was actually trivial-and has added it to his CLIJ distribution and it works: ~8X speedup. For CLIJ this required compiling a native JOCL library (Java Bindings for OpenCL). To fully leverage things-particularly in CLIJ, but probably other high performance analysis pipelines-one needs native components. So for example, my initial trials with CLIJ only worked in Rosetta, the emulation environment-when everything is emulated, everything works. As I posted on Twitter, switching to native results in ~40% performance increase in a simple CPU benchmark from switching to native JRE results in issues: you can’t mix architectures.
0 Comments
Read More
Leave a Reply. |