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)?

Show: Today's Messages :: Show Polls :: Message Navigator

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

Wed, 22 December 2010 08:04

Benjamin Bihler

Messages: 20
Registered: July 2009

Junior Member

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

Report message to a moderator

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

Fri, 14 January 2011 09:34

Benjamin Bihler

Messages: 20
Registered: July 2009

Junior Member

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

Report message to a moderator

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

Fri, 14 January 2011 12:44

Paul Webster

Messages: 6859
Registered: July 2009
Location: Ottawa

Senior Member

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

Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions

Report message to a moderator

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

Fri, 14 January 2011 13:54

Benjamin Bihler

Messages: 20
Registered: July 2009

Junior Member

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.

Report message to a moderator

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

Fri, 14 January 2011 13:56

Marco Maccaferri

Messages: 147
Registered: July 2009

Senior Member

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.

Report message to a moderator

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

Fri, 14 January 2011 14:10

Benjamin Bihler

Messages: 20
Registered: July 2009

Junior Member

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?

Report message to a moderator

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

Fri, 14 January 2011 14:26

Marco Maccaferri

Messages: 147
Registered: July 2009

Senior Member

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.

Report message to a moderator

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

Fri, 14 January 2011 14:29

Marco Maccaferri

Messages: 147
Registered: July 2009

Senior Member

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.

Report message to a moderator

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

Mon, 17 January 2011 07:55

Benjamin Bihler

Messages: 20
Registered: July 2009

Junior Member

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...

Report message to a moderator

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

Thu, 20 January 2011 10:33

Benjamin Bihler

Messages: 20
Registered: July 2009

Junior Member

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

Report message to a moderator

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 [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Apr 20 01:19:16 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter