Getting "java.lang.UnsatisfiedLinkError: no junixsocket-linux-1.5-amd64"

[GoogleCodeExporter]

Hi.

I'm getting the error below:

Exception in thread "main" java.lang.UnsatisfiedLinkError: no
junixsocket-linux-1.5-amd64 in java.library.path
            at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1709)
            at java.lang.Runtime.loadLibrary0(Runtime.java:823)
            at java.lang.System.loadLibrary(System.java:1028)
            at
org.newsclub.net.unix.NativeUnixSocket.<clinit>(NativeUnixSocket.java:73)
            at
org.newsclub.net.unix.AFUNIXServerSocket.<init>(AFUNIXServerSocket.java:49)
            at
org.newsclub.net.unix.AFUNIXServerSocket.newInstance(AFUNIXServerSocket.java:62)
            at
neo.helper.tests.junixSocketServer.main(junixSocketServer.java:17)

I think I tried every jar. Still this error on: 

AFUNIXServerSocket server = AFUNIXServerSocket.newInstance();

Thanks.

Original issue reported on code.google.com by Stas.Os...@gmail.com on 12 Nov 2009 at 3:24

[GoogleCodeExporter]

Did your build produce a file "libjunixsocket-linux-1.5-amd64.so" (it should be 
in
the lib-native" directory)?

If it did, did you set java.library.path when testing?

Original comment by tmi...@gmail.com on 18 Nov 2009 at 8:28

[GoogleCodeExporter]

I guess problems related to java.library.path may be the #1 show stopper, even 
though
they can easily be resolved once you know where to put the library file.

To improve debugging, I will add the list of checked paths to the Exception 
message
in the next release.

Stas: Have you tried tmikov's suggestion? Do you still have problems getting it 
to run?

Cheers,
Christian

Original comment by ckkohl79 on 3 Dec 2009 at 1:00

• Changed state: Started
• Added labels: Milestone-Release1.1, Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I have improved the error reporting in NativeUnixSocketImpl. The code is in SVN 
(r17).

Stas: Could you please try it again with that version? If you still get an 
error, the
message should help you finding a place where to put the
libjunixsocket-linux-1.5-amd64.so.

Original comment by ckkohl79 on 3 Dec 2009 at 1:36

• Changed state: Fixed

[GoogleCodeExporter]

Hi.

Sorry for not responding sooner, I somehow missed this email.

I got it fixed by copying the libjunixsocket-linux-1.5-amd64.so lib to /usr/lib/
directory, which granted not the best approach.

I also managed to fix it by adding it to LD_LIBRARY_PATH before running the app.

Is there any other way to make Java app locate it, preferably loading the lib 
from
the jar?

Thanks for the help.

Original comment by Stas.Os...@gmail.com on 3 Dec 2009 at 6:23

[GoogleCodeExporter]

Btw, can this ticket be re-opened?

Thanks.

Original comment by Stas.Os...@gmail.com on 3 Dec 2009 at 6:25

[GoogleCodeExporter]

You can put the native library anywhere in your java.library.path (see 
http://java.sun.com/docs/books/jni/html/start.html), into the path specified 
for the Java property 
org.newsclub.net.unix.library.path and into the path stored in the 
NativeUnixSocketConfig.LIBRARY_PATH static 
attribute (which is /opt/newsclub/lib-native by default).

I have reopened the issue, but I guess it is purely a documentation-related 
issue (admittedly there is not much 
documentation yet).

Original comment by ckkohl79 on 3 Dec 2009 at 6:45

• Changed state: Started
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I have added some documentation in the Wiki.
There is also a new version of junixsocket (1.1). Could you please try that and 
see
if it works?

Cheers,
Christian

Original comment by ckkohl79 on 3 Dec 2009 at 10:06

[GoogleCodeExporter]

Hi.

So the latest 1.1 should work from a single jar then?

Regards.

Original comment by Stas.Os...@gmail.com on 4 Dec 2009 at 1:02

[GoogleCodeExporter]

Hi Stas,

no, you still need to put the native library onto your file system.
junixsocket 1.1 gives you a more readable error message showing the paths where 
it
has looked for the native libraries (you just put them there and it works the 
next
time you start it).

Generally, I don't think it is a good idea to bundle native code with java 
classes.

Especially in multi-platform systems you would need to include all necessary 
binaries
in the jar file. You cannot build such a jar file on one single platform (e.g., 
you
cannot build OS X binaries on Linux). Moreover, for each new platform you would 
have
to modify the jar, which is probably also not so obvious.

There are workarounds for this scenario (e.g., using a custom ClassLoader that
extracts the library from within the jar file to an outer, temporary directory 
and
then loads it from there using System.load("...")), but I am not really 
convinced to
include this feature into junixsocket by default.

Best,
Christian

Original comment by ckkohl79 on 4 Dec 2009 at 9:25

• Added labels: Priority-Low
• Removed labels: Priority-High

[GoogleCodeExporter]

Hi.

Please take a look at JNA, where they include all the native libs into a single 
JAR.

https://jna.dev.java.net/

While it makes it a bit larger, the convenience far outweighs the increase in 
size.
I thinks this approach can be implemented by junixsocket as well.

Or you might provide 2 versions - one with native libs included, and one 
without.

But I really think the drop-in functionality would be the best.

Regards.

Original comment by Stas.Os...@gmail.com on 9 Dec 2009 at 12:03

[GoogleCodeExporter]

For my 2c - I think you shouldn't complicate what is a simple and useful 
package. The 
native .so is nicely isolated and auditable. If setting java.library.path is a 
problem, users can install the .so in /usr/local/lib together with all other 
shared 
libraries. It is a shared lib and should be treated no differently.

Hiding it in a jar not only delays application startup but creates security 
problems 
while bringing no advantages. JNA, although convenient, has similar 
implications.

regards,
Tzvetan

Original comment by tmi...@gmail.com on 21 Dec 2009 at 12:18

[GoogleCodeExporter]

Hi.

Setting the java.library.path is as simple as setting a simple property?

Regards.

Original comment by Stas.Os...@gmail.com on 21 Dec 2009 at 10:34

[GoogleCodeExporter]

Stas, yes, setting java.library.path is very easy:

  java -Djava.library.path=path ...

Keep in mind that it can only be set on startup.

regards,
Tzvetan

Original comment by tmi...@gmail.com on 22 Dec 2009 at 2:39

[GoogleCodeExporter]

Hi.

Can it be set from inside the code, via System.setProperty()?

Regards.

Original comment by Stas.Os...@gmail.com on 22 Dec 2009 at 9:49

[GoogleCodeExporter]

Not officially (although IIRC there are VM-dependent ways); it has to be 
specified on 
the command line.

Original comment by tmi...@gmail.com on 22 Dec 2009 at 7:10

[GoogleCodeExporter]

There are several ways to specify the path to the native junixsocket libraries.

The probably easiest one is to put them into /opt/newsclub/lib-native/ (that's a
hardcoded path defined in NativeUnixSocketConfig.java).

You can also set the path using
System.setProperty("org.newsclub.net.unix.library.path", "path-to-library-dir");

Please tell me if that works for you.

Christian

Original comment by ckkohl79 on 22 Dec 2009 at 7:32

[GoogleCodeExporter]

Christian, 
To be honest I think that all these complications are completely unnecessary 
and in a 
sense undesirable. This is an excellent library (I am using it with great 
success and 
it will soon be part of a shipping product), but it is a small and basic one. 
Yet it 
comes with a bunch of specifics - hardcoded directories and alternative ways to 
specify the library location. 

When diagnosing a problem I don't want to have different rules for different 
libraries. I don't want the possibility of the path changing at runtime.

These are unproductive details that complicate testing. In a bigger project it 
doesn't make sense to pay so much attention to one library - all .so-s simply 
go to 
one place - either /usr/[local]/lib, or somewhere within java.library.path. 

In a word, why don't you keep it as simple as possible. Is there a realistic 
scenario 
where all these additional ways to specify the .so path are necessary?

regards,
Tzvetan

Original comment by tmi...@gmail.com on 22 Dec 2009 at 9:24

[GoogleCodeExporter]

Tzvetan,

great to hear that junixsocket is useful to you.

The additional ways to specify the library location are necessary for other 
projects in multi-platform 
environments. The options are unobtrusive and can be disabled when necessary. 

As you can see from Stas' request there seems to be a need for simple 
deployment, and these additional 
library locations are a step towards it.

Best,
Christian

Original comment by ckkohl79 on 22 Dec 2009 at 9:57

[GoogleCodeExporter]

Hi again.

I might have found an good solution for this issue, which another project seems 
to be
using successfully:
http://one-jar.sourceforge.net/

Most notably is this section:
http://one-jar.sourceforge.net/index.php?page=introduction&file=native

This looks to me as a possible solution, and the author could distribute 2 
versions
of the JAR, if preferred:

* Light JAR, with JNI outside
* Full JAR, packed via one-jar

Just my 2c for the matter.

Regards.

Original comment by Stas.Os...@gmail.com on 5 Jan 2010 at 4:34

[GoogleCodeExporter]

Hi,
One-JAR makes a certain amount of sense at the application level. However it 
doesn't 
belong at the individual library level - a library shouldn't be enforcing such 
policy 
decisions on the users of the library.

Not to mention that packing native code in the jar violates the policies of 
many 
Linux distributions and is a _huge_ security risk.

If One-JAR is suitable for your case, why not simply use it at the app level to 
package Junixsocket along with everything else your app needs? 

regards,
Tzvetan

Original comment by tmi...@gmail.com on 5 Jan 2010 at 6:02

[GoogleCodeExporter]

Hi.

I'm actually going to explore this approach (using the handy Eclipse FatJAR 
plug-in),
but wanted to share it here as a possible option.

Regards.

Original comment by Stas.Os...@gmail.com on 5 Jan 2010 at 6:30

[GoogleCodeExporter]

Hi Stas,
Please keep in mind that there is a security issue with unpacking the native 
libs on 
the fly. The libs will be writable by the current user, so they are modifiable 
by 
malicious code at runtime. 

This is definitely not a generally safe technique, although admittedly there 
are 
cases when it is convenient. At the very least there should be an option to 
force 
using external libraries instead of unpacking them,, but from a quick 
inspection One-
JAR doesn't seem to have it.

regards,
Tzvetan

Original comment by tmi...@gmail.com on 6 Jan 2010 at 12:31

[GoogleCodeExporter]

Hi.

Thanks for the consideration, I will keep it in mind.

That said, it's less applicable in my case, as I'm using dedicated servers, 
without
external users allowed, so such option would be appreciated.

Regards.

Original comment by Stas.Os...@gmail.com on 6 Jan 2010 at 10:57

[GoogleCodeExporter]

Regarding this as "Fixed" (as above).

It appears that the other requessts in this issue are outside the scope of the
junixsocket library. Please reopen a new issue if necessary.

Original comment by ckkohl79 on 8 Apr 2010 at 7:06

• Changed state: Fixed

[GoogleCodeExporter]

I put here my code, because it could help other persons :

Create an init method which initialize the NativeUnixSocketConfig :

Class<?> c = Class.forName("org.newsclub.net.unix.NativeUnixSocketConfig");
Field[] fields = c.getDeclaredFields();
fields[0].setAccessible(true);
fields[0].set(null, "/your_path/where/the/library/is");

Jean-Vincent LEROY

Original comment by jv.le...@gmail.com on 23 Apr 2010 at 12:19

[GoogleCodeExporter]

Jean-Vincent,

I do not recommend using reflection for this purpose.

Why not just use

System.setProperty("org.newsclub.net.unix.library.path",
"/your_path/where/the/library/is");

or, preferably, specify this property when starting the java VM

java -Dorg.newsclub.net.unix.library.path=/your_path/where/the/library/is 
your.ClazzName

?

Original comment by ckkohl79 on 23 Apr 2010 at 12:24

[GoogleCodeExporter]

You are right. Actually, i put this code for some peoples which would like one
another method for unknown reasons.

I prefer using System.setProperty, but it's only a personal preference.

Original comment by jv.le...@gmail.com on 23 Apr 2010 at 12:32

[GoogleCodeExporter]

Accessing classes through reflection may not always work (because of missing 
privileges, sandbox issues etc.) 

What is especially problematic with the reflection code snippet above is that 
it does not check the name of the 
field it modifies. Well, right now, there only is one field, but this may 
change in a future release.

I would really recommend setting the system property rather than using 
reflection. It is much more than a 
personal preference.

Best,
Christian

Original comment by ckkohl79 on 23 Apr 2010 at 12:41

[GoogleCodeExporter]

Hi,
Although its been a long time since last activity on this thread, however im 
facing same problem. Im working on Linux 12.04LTS
I have added native library into java.library.path as follows
export LD_LIBRARY_PATH=/Home/junixsocket-1.3/lib-native:$LD_LIBRARY_PATH
then in my code I do the following 
public class SocketClient {
    public static void main(String[] args) throws IOException {
        System.setProperty("org.newsclub.net.unix.library.path","/Home/junixsocket-1.3/lib-native");

But still i get the following error.
java.lang.UnsatisfiedLinkError: Could not load junixsocket library, tried 
[/Home/junixsocket-1.3/lib-native/libjunixsocket-linux-1.6-i386.so, 
/Home/junixsocket-1.3/lib-native/libjunixsocket-linux-1.5-i386.so, 
lib:junixsocket-linux-1.6-i386, lib:junixsocket-linux-1.5-i386]; please define 
system property org.newsclub.net.unix.library.path

I dont understand that why it is looking for libjunixsocket-linux-1.6-i386.so. 
And even though it is looking under the directory where the .so file is present 
even then it is not able to find it.

Please help me in this matter.
Regards.
R

Original comment by s.moh.r...@gmail.com on 27 Jun 2013 at 10:50