java-native-access / jna

Java Native Access
Other
8.52k stars 1.68k forks source link

java.lang.UnsatisfiedLinkError /lib64/libc.so.6: version `GLIBC_2.11' not found #52

Closed jhorstmann closed 12 years ago

jhorstmann commented 12 years ago

JNA 3.40 seems to use a symbol from libc version 2.11, it would be great if it could be made to work also with older versions.

Running a program using JNA 3.4.0 results in the following stacktrace, downgrading to JNA 3.2.7 solved the problem.

java.lang.UnsatisfiedLinkError: /tmp/jna/jna6331993596205149685.tmp: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by /tmp/jna/jna6331993596205149685.tmp)
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1803)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1699)
        at java.lang.Runtime.load0(Runtime.java:770)
        at java.lang.System.load(System.java:1003)
        at com.sun.jna.Native.loadNativeLibraryFromJar(Native.java:771)
        at com.sun.jna.Native.loadNativeLibrary(Native.java:697)
        at com.sun.jna.Native.<clinit>(Native.java:127)
        at de.beit.adpPortal.geraetepark.FreischaltcodeJNA.<clinit>(FreischaltcodeJNA.java:15)
        at de.beit.adpPortal.geraetepark.FreischaltcodeTest.testAlt(FreischaltcodeTest.java:7)

Inspecting the dynamic library reveals the following details:

$ objdump -p com/sun/jna/linux-amd64/libjnidispatch.so 
com/sun/jna/linux-amd64/libjnidispatch.so:     file format elf64-x86-64
...
Version References:
  required from libc.so.6:
    0x06969191 0x00 05 GLIBC_2.11
    0x0d696914 0x00 04 GLIBC_2.4
    0x09691974 0x00 03 GLIBC_2.3.4
    0x09691a75 0x00 02 GLIBC_2.2.5

$ objdump -t com/sun/jna/linux-amd64/libjnidispatch.so  | grep 2.11
0000000000000000       F *UND*  0000000000000000              __longjmp_chk@@GLIBC_2.11
twall commented 12 years ago

updated linux binaries for x86/amd64 against 2.1.3 and 2.2.5, respectively.

rdp commented 12 years ago

I think I just got this same error message from jnaerator with its "shaded" jar. Guess I'll put the newer jna.jar first in the classpath for now...

twall commented 12 years ago

no. the binaries have been checked in but not yet tagged or released

On Feb 16, 2012, at 4:13 PM, Roger Pack wrote:

has this been released yet? I still seem to be getting it with the 3.4.0 binaries linked to here: https://github.com/twall/jna


Reply to this email directly or view it on GitHub: https://github.com/twall/jna/issues/52#issuecomment-4009575

Zlika commented 12 years ago

I'm also facing this bug. Do you plan to release a new JNA version anytime soon ?

twall commented 12 years ago

It was waiting on someone to review and/or fix the maven release bits, but no one has stepped forward.

If that situation continues, I can tag and release next week sometime. That said, a working version is available from the repo at any time.

T.

On May 4, 2012, at 6:12 AM, Zlika wrote:

I'm also facing this bug. Do you plan to release a new JNA version anytime soon ?


Reply to this email directly or view it on GitHub: https://github.com/twall/jna/issues/52#issuecomment-5507608

Zlika commented 12 years ago

I use maven, so I try to only use the versions that are on maven central (with an "official" numbering).

maxcom commented 12 years ago

Same problem on 3.5.0. Last version that works on RHEL5 is 3.3.0

twall commented 12 years ago

If you need to specifically target older releases, you might want to build your own.

I don't have any older 64-bit build platforms.

On Oct 20, 2012, at 7:07 AM, Maxim Valyanskiy wrote:

Same problem on 3.5.0. Last version that works on RHEL5 is 3.3.0

— Reply to this email directly or view it on GitHub.

diakula commented 11 years ago

Well, I understand that the latest JNA has been build against a fresh updated OS. JNA is a great package that has served us very well.

Nevertheless, we have this issue and it is not so simple to upgrade our machines. When I checked JDK 7u5, it requires GLIBC 2.5.

Currently, you have a case in which backward compatibility breaks:

The cleanest approach would be:

If you don't do this, you will be loosing clients from all kinds of conservative installations such as long support Debian and BSD clones, who do not want to unnecessarily upgrade something that works rather well.