Support LTS distributions

[PeteSL]

JNA 4.3.0
Oracle Java 8 Compact 3
Centos 5
32 bit
Upgraded from JNA 4.2.2 and got the tiled error. Went back to 4.2.2 and no error. While Centos 5 is reaching end of life, the dependency on a c library not available in the OS will prevent our users from upgrading. Similar to closed issue in 2012.

[matthiasblaesing]

The native parts had to be rebuild for 4.3 as a serious bugfix needed changes in the native interface. I was only able to rebuild most of the linux libraries because I could setup a chroot build with debian and do the building there.

If centos offers something like debian backports, I suggest to rebuild the JNA for Centos 5 and provide it there.

[PeteSL]

That I do not know. I am not a Linux guru nor am I able to do any builds for Linux as I do not have any Linux development machines. As the case in 2012 talked about, there probably needs to be a check to determine available c library version numbers (not only for Linux but also for Windows and probably other OSes). I know this is a big headache but we can't assume that all systems are running the latest software across the board. Just my opinion.

[matthiasblaesing]

I take suggestions how to setup a cross-platform build (that is as simple as my current debian chroot setup) and I'll see if old-stable is good enough to build JNA. I don't know when that will happen.

[matthiasblaesing]

Could you please state your platform? I was able to rebuild JNA on debian oldstable armhf. I would like to rebuild JNA 4.3.0 with oldstable and then ask you to test if that is old enough.

[PeteSL]

Centos 5.2, x86 (32 bit), Java 8 SE Compact 3 VM. Hope this helps.

[matthiasblaesing]

Ok - here is a SNAPSHOT build:

http://www.doppel-helix.eu/jna.jar

This build is from JNA master (the upcoming 4.4.0 release) and contains linux i386 (32bit) und amd64 binaries build with a toolchain from debian-stable. Please see if these work for you.

[PeteSL]

Will do. Just to verify, other than being based on the upcoming 4.4 release, the only binary change is to the Linux binaries, correct? Just checking if I should also test on my armhf and Windows 64 test machines.

[matthiasblaesing]

Feel free to test on windows 64 - the windows binaries were rebuild with the Visual Studio 2015 toolchain, as prior to that C99 bools were not supported.

The linux armhf binaries will be build on respbian-arm6l, that might still be a problem for you, but debians arm32 release is not compatible with raspberry pi.

[PeteSL]

It failed on Centos 5.2 still looking for GLIB 2.17. 4.3 is working on my Win 64 and RPi 2 so I am not going to worry beyond that at this time. I will continue to use 4.2.2 on CentOS 5.x since it is EOL this year, if I remember correctly.

[matthiasblaesing]

Thanks for testing. I confirm your finding. My build pipeline is currently based on debian changeroots, that are run in a qemu-static environment. So debian stable is currently the baseline distribution. If someone can offer a similiar setup with centos I'm willing to set that up and rebuild.

For now I conclude work on this.

[matthiasblaesing]

Here is a snapshot build of the suggested native libraries in #840:

jna.zip

Please have a look and test if you find these usable on LTS distributions (CentOS/RHEL/SLES).

[raspy]

This still fails on RHEL 5, since it uses GLIBC 2.5. As RHEL 5 is in extended support phase till 2020, would it be possible to recompile the libraries to lower GLIBC dependencies?

[matthiasblaesing]

Sure it would be. But I'm currently the only one build native libraries and I currently have 2 qemu virtual machines and 7 debian chroots in a VM for linux. Building in the chroots is ok and results in stable glibc dependendencies. If you can provide a guide how to setup a rhel/centos 5 changeroot from command line , that includes a java version, I'm willing to have a look (the chroots mentioned above are are build with debootstrap/qemu-debootstrap).