Eclipse Community Forums: Rich Client Platform (RCP) » Workaround for Bug 139064 on Linux (JNI: UnsatisfiedLinkError)?

Home » Eclipse Projects » Rich Client Platform (RCP) » Workaround for Bug 139064 on Linux (JNI: UnsatisfiedLinkError)?

Workaround for Bug 139064 on Linux (JNI: UnsatisfiedLinkError)? [message #646113]

Wed, 22 December 2010 03:04

Eclipse User

Hi,

does anybody know a workaround for this bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=139064
on Linux?

I have to load native libraries for which I do not have the source code. System.loadLibrary(...) works for libraries without dependencies, but when I load a library that was linked against another shared library I get an UnsatisfiedLinkError with the error message that this other library cannot be found. Both libraries are located at the root folder of the plug-in that tries to load them.

For Windows systems there is a workaround: base libraries have to be loaded first and depending libraries can be loaded afterwards, but this does not work with Linux systems.

Does anybody know a solution or a workaround for this bug?

The only one I know is to set the environment variable LD_LIBRARY_PATH to contain the plug-in root path, but this is very inconvenient when the product has to be deployed.

Is there a better solution? Any help is greatly appreciated.

Thank you very much,
Benjamin

Re: Workaround for Bug 139064 on Linux (JNI: UnsatisfiedLinkError)? [message #648727 is a reply to message #646113]

Fri, 14 January 2011 04:34

Eclipse User

Hi,

unfortunately nobody seems to know a solution.

My workaround therefore is to set the environment variable LD_LIBRARY_PATH to contain all libraries on every Unix system the product is installed on. This is very inconvenient since the libraries are part of fragments that have the ".qualifier" included in their version.

Therefore I have to do something like

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/ProductPath/plugins/MyFrag ment_1.3.0.2011011410

before the user starts the product.

Is there any easy way to do that automatically? If the product export does not support something like that is there any other build tools that can be used to set environment variables like that automatically without manually specifying the fragment path generated by the product export?

Any help is greatly appreciated.

Thanks,
Benjamin

Re: Workaround for Bug 139064 on Linux (JNI: UnsatisfiedLinkError)? [message #648759 is a reply to message #646113]

Fri, 14 January 2011 07:44

Eclipse User

On 12/22/2010 03:04 AM, Benjamin Bihler wrote:
> I have to load native libraries for which I do not have the source code.
> System.loadLibrary(...) works for libraries without dependencies, but
> when I load a library that was linked against another shared library I
> get an UnsatisfiedLinkError with the error message that this other
> library cannot be found. Both libraries are located at the root folder
> of the plug-in that tries to load them.

Are both libraries mentioned in your Bundle-NativeCode?

PW

--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Platform_Expression_Framework
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm

Re: Workaround for Bug 139064 on Linux (JNI: UnsatisfiedLinkError)? [message #648779 is a reply to message #648759]

Fri, 14 January 2011 08:54

Eclipse User

Paul Webster wrote on Fri, 14 January 2011 07:44

Are both libraries mentioned in your Bundle-NativeCode?

They had not been. But now I have added the following to MANIFEST.MF of my fragment containing the native libraries:

Bundle-NativeCode: lib1.so ; lib2.so ;
osname=linux;
processor=x86_64

It does not change anything. I get the same exception.

Re: Workaround for Bug 139064 on Linux (JNI: UnsatisfiedLinkError)? [message #648782 is a reply to message #648727]

Fri, 14 January 2011 08:56

Eclipse User

On 14/01/2011 10:34 Benjamin Bihler ha scritto:

> unfortunately nobody seems to know a solution.
>
> My workaround therefore is to set the environment variable
> LD_LIBRARY_PATH to contain all libraries on every Unix system
> the product is installed on. This is very inconvenient since
> the libraries are part of fragments that have the ".qualifier"
> included in their version.

Interesting, I have a project with a similar setup and the libraries are
loaded correctly on Linux. The approach I took however is a bit different.

The native code is bundled in a fragment. The libraries are not listed
in the BundleNativeCode tag but are located at the root of the fragment.
The bundle activator then loads both libraries in dependency order
(jni library is the last). The fragment is also unpacked in the product
installation directory.

Hope this helps.

Re: Workaround for Bug 139064 on Linux (JNI: UnsatisfiedLinkError)? [message #648788 is a reply to message #648782]

Fri, 14 January 2011 09:10

Eclipse User

Marco Maccaferri wrote on Fri, 14 January 2011 08:56

Interesting, I have a project with a similar setup and the libraries are
loaded correctly on Linux. The approach I took however is a bit different.

The native code is bundled in a fragment. The libraries are not listed
in the BundleNativeCode tag but are located at the root of the fragment.
The bundle activator then loads both libraries in dependency order
(jni library is the last). The fragment is also unpacked in the product
installation directory.

It is absolutely the same with me. I have also put the native code into the root directory of a fragment. I also unpack the fragment. If have tried both - with and without BundleNativeCode. I always get an the mentioned exception.

Can it be that there is a difference with the libraries? Perhaps with linker options or something like that?

Re: Workaround for Bug 139064 on Linux (JNI: UnsatisfiedLinkError)? [message #648796 is a reply to message #648788]

Fri, 14 January 2011 09:26

Eclipse User

On 14/01/2011 15:10 Benjamin Bihler ha scritto:

> Can it be that there is a difference with the
> libraries? Perhaps with linker options or something like that?

I'm running with 64bit Linux, I don't know if it makes any difference.
About the libraries, the first is a third-party library compiled with
its own setup (standard Linux toolchain, compiled with the classic
../configure make commands). The jni library is compiled with Eclipse CDT
with roughly the default settings (the command is g++ -O3 -Wall -c
-fmessage-length=0 -fPIC -MMD -MP). Linker is also standard, no more
than g++ -shared.

Re: Workaround for Bug 139064 on Linux (JNI: UnsatisfiedLinkError)? [message #648797 is a reply to message #648788]

Fri, 14 January 2011 09:29

Eclipse User

On 14/01/2011 15:10 Benjamin Bihler ha scritto:

> Can it be that there is a difference with the libraries?
> Perhaps with linker options or something like that?

Almost forgot again: the product is compiled against Eclipse 3.5.2.

Re: Workaround for Bug 139064 on Linux (JNI: UnsatisfiedLinkError)? [message #649000 is a reply to message #648796]

Mon, 17 January 2011 02:55

Eclipse User

Marco Maccaferri wrote on Fri, 14 January 2011 09:26

I'm running with 64bit Linux, I don't know if it makes any difference.
About the libraries, the first is a third-party library compiled with
its own setup (standard Linux toolchain, compiled with the classic
../configure make commands). The jni library is compiled with Eclipse CDT
with roughly the default settings (the command is g++ -O3 -Wall -c
-fmessage-length=0 -fPIC -MMD -MP). Linker is also standard, no more
than g++ -shared.

I do not see any substantial difference here. My libraries are compiled with
g++ --shared -fPIC ...
and the executable is linked with
g++ -Wl,-rpath-link...
so that the library dependencies can be resolved.

On the other hand: are there many programmers loading native libraries with dependencies in eclipse fragments? If this worked, the bug mentioned in my first message would not be marked as "NEW" but as "SOLVED" instead, right?! Sad, sad...

Re: Workaround for Bug 139064 on Linux (JNI: UnsatisfiedLinkError)? [message #649687 is a reply to message #646113]

Thu, 20 January 2011 05:33

Eclipse User

Hi,

may I repeat my question?

I have to set the environment variable LD_LIBRARY_PATH to contain all libraries on every Unix system the product is installed on. This is very inconvenient since the libraries are part of fragments that have the ".qualifier" included in their version.

Therefore I have to do something like

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/ProductPath/plugins/MyFrag ment_1.3.0.2011011410

before the user starts the product.

Is there any easy way to do that automatically? If the product export does not support something like that is there any other build tools that can be used to set environment variables like that automatically without manually specifying the fragment path generated by the product export?

Any help is greatly appreciated.

Thanks,
Benjamin

Previous Topic:	how to specify the path of a file bundled in the package
Next Topic:	Eclipse Jobs Usage query

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 22 12:43:10 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter