Request for GLIBC 2.5+ support (JNA 3.4.0, 3.5.0 and 3.5.1 require newer)

[diakula]

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:
A system S with GLIBC 2.5+ (< 2.11) runs OK with older version of JNA and JDK 7u5
Someone starts using JNA latest on S
JNA latest claims it works with JDK7u5 but fails to run properly.

The cleanest approach would be:
check which Java versions (update including) you want to claim JNA compatible with,
check which GLIBC versions they support
make sure JNA support those.
for all other Java updates/versions, make conditional notice in the release notes that the OS has to be newer than some version (currently GLIBC 2.11)

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.

[diakula]

3.3.0:
38 GLIBC_2.2.5
3.4.0:
1 GLIBC_2.11
36 GLIBC_2.2.5
3 GLIBC_2.3.4
1 GLIBC_2.4
3.5.0:
1 GLIBC_2.11
34 GLIBC_2.2.5
3 GLIBC_2.3.4
1 GLIBC_2.4
3.5.1:
1 GLIBC_2.11
34 GLIBC_2.2.5
3 GLIBC_2.3.4
1 GLIBC_2.4

Basically, we can only use 3.3.0, which is compatible with JDK 5's requirement of GLIBC 2.5.
Our recommendation is JNA to depend at most on 2.5, in order to not block usage on wide-range of existing deployments of Java.

[twall]

It all depends on the build environments I have available. I have an ubuntu/i386 with glibc 2.3.6, but most other platforms are newer.

Debian and BSD have a long tradition of building from source; doing so will ensure compatibility with any given system.

I'm not sure what your version listing is attempting to communicate - what are the multiple glibc versions listed below each JNA version?

[Stephan202]

(Colleague of OP here.)

Indeed we can build our own artifact and deploy it to our private Nexus instance, but of course we'd like to avoid "diverging" (in the broadest sense of the word) from the original release artifact if possible. The second reason for this request is that we assumed that JNA would like to be out-of-the-box compatible with as many JDK target platforms as possible.

The versioning list mentioned above enumerates aggregate GLIBC version dependency counts by JNA version. It was produced by running the following in an empty directory:

for V in 3.3.0 3.4.0 3.5.0 3.5.1; do
  echo $V:
  wget -q http://repo1.maven.org/maven2/net/java/dev/jna/jna/$V/jna-$V.jar
  unzip -qo jna-$V.jar com/sun/jna/linux-amd64/libjnidispatch.so
  nm com/sun/jna/linux-amd64/libjnidispatch.so | grep -o 'GLIBC.*' | sort | uniq -c
  rm -rf jna*
done

As you can see, the linux-amd64 dispatch library still mostly, but unfortunately not completely, requires GLIBC 2.2.5.

There are ways to target an older GLIBC than the one installed on the build system, but this appears to be quite non-trivial (source). Hypothetical question (no promise): if we can somehow provide you with a fully set-up VM image containing a sufficiently old GLIBC installation, would you be willing to use it to build subsequent JNA release artifacts?

[twall]

It's typically easiest to target a fresh installation of one of these older distributions, than to either target and older glibc than installed or make a platform available for external use. If you can point me to specific ISOs I can spin up new installs of the desired OS configurations, but I'm reluctant to spend much time chasing down appropriate VMs and assorted other packages. I'm certainly open to finding an amenable solution.

[twall]

I just checked my /lib/libc.so.6 version on my older ubuntu/64 VM, and it reports 2.3.6.

[twall]

Recompiling on that OS results in GLIBC_2.2.5 as the newest symbol present. I've pushed that change to master.

[Stephan202]

$ unzip -q linux-amd64.jar libjnidispatch.so && nm libjnidispatch.so | grep -o 'GLIBC.*' | sort | uniq -c
     39 GLIBC_2.2.5

Wow. Quick and great :)

I assume this new binary will be shipped with the upcoming release (be it 3.5.2 or 3.6.0)?

Thanks for the rapid response!

[diakula]

Excellent!

[twall]

Please raise additional, individual platforms (BSD et al.) as separate issues.