Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS no suitable image found - java JNI

D

DJRichCMusic

macrumors newbie
Original poster
Aug 31, 2010
4
0
Hi all,

I posted this on another thread for someone with similar issues, but to no avail, I will try here and hopefully someone can help me out.

I have a JNI library which I built, which works correctly with another application that I built.

I am working on a 'version 2' but the library is giving the following.

any help would be appreciated.

My Stack Trace:

Exception in thread "main" java.lang.UnsatisfiedLinkError: /Users/rcook/NetBeansProjects/MPX Print Suite/libEyeOneNative.dylib: no suitable image found. Did find: /Users/rcook/NetBeansProjects/MPX Print Suite/libEyeOneNative.dylib: mach-o, but wrong architecture
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1823)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1746)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1045)
at com.mpx.device.eyeone.EyeOneDevice.<init>(EyeOneDevice.java:25)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at com.mpx.plugin.device.PluginDeviceLoader.loadDevices(PluginDeviceLoader.java:52)
at com.mpx.plugin.device.PluginDeviceLoader.getInstance(PluginDeviceLoader.java:29)
at com.mpx.printsuite.TestDevicePlugin.main(TestDevicePlugin.java:22)


Lipo:

Non-fat file: libEyeOneNative.dylib is architecture: i386


Java Version:

java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)


Many thanks in advance.


Regards

Richard
 
wrldwzrd89

wrldwzrd89

macrumors G5
Jun 6, 2003
12,110
77
Solon, OH
The error message posted suggests right away what the problem is. You have an Intel Mac, no? You're trying to run 64-bit Java (the default on Snow Leopard) with a 32-bit .dylib. That won't work. You need to either compile a 64-bit version of your .dylib file, or run Java in 32-bit mode.
 
D

DJRichCMusic

macrumors newbie
Original poster
Aug 31, 2010
4
0
Thanks for your prompt reply.

I thought this myself but the dylib works fine with my other aplication.

I am running it through the ide rather standalone, this might have something to do with it.

I'l have a play.

Thanks again
 
F

foidulus

macrumors 6502a
Jan 15, 2007
904
1
DJRichCMusic said:
Thanks for your prompt reply.

I thought this myself but the dylib works fine with my other aplication.

I am running it through the ide rather standalone, this might have something to do with it.

I'l have a play.

Thanks again
Click to expand...

The IDE(if you are launching it from an app bundle) may very well specify use 32 bit(or just have a 32 bit Java application stub, no 64 bit stub).

If you launch with a 32 bit stub the OS automatically loads the 32 bit java no matter what the order of the jvms is in your preferences. However if you launch it via the java command(or just double clicking on the jar), it will take your preferences into account and like was said before defaults into 64 bit.
 
chown33

chown33

Moderator
Staff member
Aug 9, 2009
10,743
8,417
A sea of green
DJRichCMusic said:
I thought this myself but the dylib works fine with my other aplication.
Click to expand...

Any application that requires a specific JVM 64-bit or 32-bit mode must specify its needs. Failure to do this means it's at the mercy of the user's preference, as set by Java Preferences.app. Or it's at the mercy of whatever IDE is launching it, using whatever launch mechanism the IDE uses.

Depending on how the failing application is launched, you will have to do one of the following:
1. In a shell or command-line, use the -d32 option.
2. In a bundled app, remove the slice from the stub executable for the architecture NOT supported, leaving only the architecture that IS supported.

If the Java application is launched via JNLP, there is a JNLP option for this. Refer to the JNLP spec and look for the arch options.

If the Java application is launched by double-clicking a jar-file, then you have no control over the 32 or 64 bit arch. It will always follow the user's preference.

An IDE is probably using a command-line or shell, but you should check the docs for the IDE. There should be a way to specify what the JVM launch options are for a project or target. These aren't necessarily the same as the JVM launch options for the IDE itself.

Removal of a slice from the executable stub is done using the 'lipo' command.

Reference for 'java' command, discussing -d32 and -d64:
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/java.1.html
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom