(feature) Support Linux distros older than 2018

[rwst]

Is your feature request related to a problem? Please describe.
The problem is I can't readily upgrade my OS to work around the crash I get when running conveyor:

./conveyor-7.2/bin/conveyor: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /home/ralf/conveyor-7.2/bin/../lib/runtime/lib/server/libjvm.so)
./conveyor-7.2/bin/conveyor: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /home/ralf/conveyor-7.2/bin/../lib/runtime/lib/server/libjvm.so)

Describe the solution you'd like
Provide a conveyor binary that doesn't lock glibc version

Describe alternatives you've considered
Upgrading my OS.

[mikehearn]

Hi,

What distro and version of Linux are you using, and what's the underlying reason you can't upgrade? glibc 2.27 came out in 2018. We can look at supporting older Linuxes but this is actually a dependency of the Java runtime we use, so it could be quite hard to do this.

[rwst]

This is OpenSUSE Leap 15.2 and the upgrade appears to be quite difficult. Anyway, I know it is my problem so I didn't file a bug request. Still, I would think that removing the dependency on your side woud be a valuable feature.

Also I don't understand why I can run Java 20 on this machine but not your binary:

ralf@ark:~> ldd /opt/jdk-20/bin/java
	linux-vdso.so.1 (0x00007ffe5ff6c000)
	libz.so.1 => /lib64/libz.so.1 (0x00007ff4b4675000)
	libjli.so => /opt/jdk-20/bin/../lib/libjli.so (0x00007ff4b4a64000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff4b4456000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007ff4b4252000)
	libc.so.6 => /lib64/libc.so.6 (0x00007ff4b3e97000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ff4b488c000)

[mikehearn]

Are you sure you can run it? ldd doesn't actually run the program. If it does run then yes that would be curious.

[mikehearn]

Actually thinking about it, we do our own JVM builds (of 17). If 20 does run then it suggests it doesn't really need the new glibc symbols and we could maybe downgrade our requirements, albeit maybe not quite that far (we'd have to test it etc).

You could also try a container of a newer distro, if that version of OpenSUSE supports it?

[rwst]

Confirm that java-20 actually runs, for example a desktop app.

[mikehearn]

OK. We could potentially build against an older glibc then to avoid that problem. Or just patch the binaries to use older symbol versions - I've never yet encountered an app that breaks when pointed to older symbols. It could even be a Conveyor feature, perhaps.

It'd help for prioritization to know if this would be a commercial project. Presumably you have to use this old distro because you're at work in some sort of enterprise or scientific org?

[rwst]

I decided to do an OS update. The software project would be Open Source, supporting my work as biocurator at reactome.org which produces open data. So it is your decision if the fix is worth it.

As to the different behaviour of your package vs Java 20, I suspect the culprit libjvm.so is the interface between your C++ and JVM, and as such libc dependent.

[mikehearn]

libjvm is the JVM, but we have a few backported bug fixes in a fork of it to resolve compatibility issues on other operating systems. At some point we'll unfork and then we can go back to using upstream builds, which are built against old libcs. Great to hear you got it working, I'll close this ticket.

[mikehearn]

Actually, I guess we can leave it open with a different title to reflect the issue.