Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unsatisfied link error when running on FreeBSD #302

Closed
rtyler opened this issue Jan 26, 2014 · 7 comments
Closed

Unsatisfied link error when running on FreeBSD #302

rtyler opened this issue Jan 26, 2014 · 7 comments
Labels

Comments

@rtyler
Copy link

rtyler commented Jan 26, 2014

I'm calling Native.loadLibrary("c", BSDCLibrary.class) from my FreeBSD (amd64) machine.

Running with jna.debug_load set, e.g.

$ mvn -Djna.debug_load=true test

Results in this:

Looking for library 'c'
Adding paths from jna.library.path: null
Trying libc.so
Adding system paths: [/usr/lib, /lib]
Trying /usr/lib/libc.so
Looking in classpath from sun.misc.Launcher$AppClassLoader@3f0dbef1 for c
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.164 sec <<< FAILURE!
testgetPwName(org.jvnet.libpam.UnixUserTest)  Time elapsed: 0.09 sec  <<< ERROR!
java.lang.UnsatisfiedLinkError: Unable to load library 'c': Native library (freebsd-x86-64/libc.so) not found in resource path ([file:/usr/home/tyler/source/github/libpam4j/target/surefire/surefirebooter674054672
0100787544.jar])
        at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:271)
        at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:398)
        at com.sun.jna.Library$Handler.<init>(Library.java:147)
        at com.sun.jna.Native.loadLibrary(Native.java:412)
        at com.sun.jna.Native.loadLibrary(Native.java:391)
        at org.jvnet.libpam.impl.CLibrary$Instance.init(CLibrary.java:138)
        at org.jvnet.libpam.impl.CLibrary$Instance.access$000(CLibrary.java:134)
        at org.jvnet.libpam.impl.CLibrary.<clinit>(CLibrary.java:132)
        at org.jvnet.libpam.impl.CLibrary$passwd.loadPasswd(CLibrary.java:61)
        at org.jvnet.libpam.UnixUser.<init>(UnixUser.java:87)
        at org.jvnet.libpam.UnixUserTest.testgetPwName(UnixUserTest.java:32)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
        at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
        at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
        at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
        at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

For whatever reason, /usr/lib/libc.so is actually a text file:

/* $FreeBSD$ */
GROUP ( /lib/libc.so.7 /usr/lib/libc_nonshared.a /usr/lib/libssp_nonshared.a )

I'm not sure if this is a bug that JNA should fix, or if the "resolution" is for me to just create a symlink in my library path to /lib/libc.so.7

@twall
Copy link
Contributor

twall commented Jan 27, 2014

Is this distinct from issue #279 ?

@rtyler
Copy link
Author

rtyler commented Jan 27, 2014

@twall Perhaps, was that fix not included in 4.0.0?

@twall
Copy link
Contributor

twall commented Jan 28, 2014

It’ll be in 4.0.1 whenever that gets pushed out.

On Jan 27, 2014, at 11:29 AM, R. Tyler Croy [email protected] wrote:

@twall Perhaps, was that fix not included in 4.0.0?


Reply to this email directly or view it on GitHub.

@rtyler
Copy link
Author

rtyler commented Feb 25, 2014

@twall are you folks planning on releasing a 4.0.1 any time soon? I'm hoping to see this fix included upstream inside of Jenkins :/

@twall
Copy link
Contributor

twall commented Feb 25, 2014

waiting on one of the maintainers (me, db, or dan) to get time to do it, sorry.

On Feb 24, 2014, at 10:17 PM, R. Tyler Croy [email protected] wrote:

@twall are you folks planning on releasing a 4.0.1 any time soon? I'm hoping to see this fix included upstream inside of Jenkins :/


Reply to this email directly or view it on GitHub.

@dblock dblock added the bug? label Jun 24, 2014
@rodrigc
Copy link

rodrigc commented Nov 2, 2014

This was fixed in 6f13f2e

@matthiasblaesing
Copy link
Member

This is marked as fixed.

mstyura pushed a commit to mstyura/jna that referenced this issue Sep 9, 2024
Motivation:

At the moment our code depends on sun.misc.Unsafe. We should better not do this if possible as it might go away at some point.

Modifications:

- Rewrite code to just use ByteBuffer directly and not Unsafe

Result:

No more dependency on sun.misc.Unsafe
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants