GeezerVison is showing github.com — Bug: Version 0.9.2 doesn't work anymore on RHEL 8.x · Issue #280 · lmdbjava/lmdbjava
Bug: Version 0.9.2 doesn't work anymore on RHEL 8.x #280DescriptionHello.
I wanted to updated my project to version 0.9.2 to address the found regression, but it now fails with
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.UnsatisfiedLinkError: /lib64/libc.so.6: version `GLIBC_ABI_DT_RELR' not found (required by /tmp/lmdbjava-native-library-666798517959064055.so)
Library names
[/tmp/lmdbjava-native-library-666798517959064055.so]
Search paths:
[/usr/java/packages/lib, /usr/lib64, /lib64, /lib, /usr/lib, /usr/local/lib] [in thread "main"]
at jnr.ffi.provider.jffi.NativeLibrary.loadNativeLibraries(NativeLibrary.java:111)
at jnr.ffi.provider.jffi.NativeLibrary.getNativeLibraries(NativeLibrary.java:85)
at jnr.ffi.provider.jffi.NativeLibrary.getSymbolAddress(NativeLibrary.java:64)
at jnr.ffi.provider.jffi.NativeLibrary.findSymbolAddress(NativeLibrary.java:74)
at jnr.ffi.provider.jffi.AsmLibraryLoader.generateInterfaceImpl(AsmLibraryLoader.java:141)
at jnr.ffi.provider.jffi.AsmLibraryLoader.loadLibrary(AsmLibraryLoader.java:87)
at jnr.ffi.provider.jffi.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:44)
at jnr.ffi.LibraryLoader.load(LibraryLoader.java:420)
at jnr.ffi.LibraryLoader.load(LibraryLoader.java:399)
at org.lmdbjava.Library.<clinit>(Library.java:72)
at org.lmdbjava.Env$Builder.open(Env.java:544)
at org.lmdbjava.Env$Builder.open(Env.java:569) @benalexau @at055612 any idea? Activitycdprete commented on Nov 18, 2025 ContributorAuthor More actions It seems like that such symbol is available from version 2.39 of glibc which is available only starting from RHEL 10.x.
@benalexau @at055612 could it be possible to release the fix for the regression in a version that uses the same binaries which were used in version 0.9.1? Alternatively, would it be possible to recompile the native library with an older version of glibc? wardle commented on Nov 18, 2025 In the meantime, I have gone back to using an explicit native library:
java -Dlmdbjava.native.lib=/usr/lib64/liblmdb.so.0.0.0 xxx.jar
The zig built libraries didn't have glibc issues, but the native ones are definitely faster in my benchmarks, even just for read operations. wardle commented on Nov 18, 2025 cdprete commented on Nov 18, 2025 ContributorAuthor More actions
In the meantime, I have gone back to using an explicit native library:
java -Dlmdbjava.native.lib=/usr/lib64/liblmdb.so.0.0.0 xxx.jar
The zig built libraries didn't have glibc issues, but the native ones are definitely faster in my benchmarks, even just for read operations.
The native version I've available is very old:
I've for now solved the issue by excluding the org.lmdbjava:native transitive dependency and adding it explicitly with version 0.9.29-1.
Of course, this is not ideal. wardle commented on Nov 18, 2025 I was trying to think of an elegant way to fix this but it is tricky. musl is an option. The other fix would be to have individual lmdbjava-native libraries for different architectures and then force users of lmdbjava to either explicitly set a flag to choose location of the native library to use (eg packaged in their distro or compiled themselves) or to include one or more lmdbjava-native packages themselves as dependencies. Alternatively there could be native glibc AND musl binaries with a choice made at runtime depending on architecture. I deploy on mac, Linux (one particularly ancient) and FreeBSD so am fairly relaxed by having to specify a manual local library but I guess it makes it just a little harder for consumers of my tooling now. Perhaps if musl doesn’t cause a performance hit, and it’s good enough for Alpine, then perhaps that might be a good option? changed the title [-]Version 0.9.2 doesn't work anymore on RHEL 8.x[/-] [+]Bug: Version 0.9.2 doesn't work anymore on RHEL 8.x[/+] on Nov 18, 2025cdprete commented on Nov 18, 2025 ContributorAuthor More actions Mmm I don't know. I like honestly the idea that the needed libraries are indeed part of the package like it is now, but on the other end I agree that's complicated to offer each and every possible combination. at055612 commented on Nov 18, 2025
Perhaps if musl doesn’t cause a performance hit, and it’s good enough for Alpine, then perhaps that might be a good option?
In some environments, our app (that used LJ) is deployed in Docker containers that are Alpine based. I suspect a lot of other people that use containers will also use an Alpine base image. LJ 0.9.2 (with embed lib) does not work with Alpine. While it is possible for the dockerfile to install lmdb using apk then set the org.lmdbjava:native prop (which does work), this then requires keeping the installed lmdb lib version in synch with what LJ expects.
I wonder if we could include the musl based alpine distribution of lmdb (as @wardle suggested) in the native repo. TargetName would need to do something like read /etc/os-release to determine if the os is Alpine in order to use it.
We can't realistically include a lib for every possible flavour of os and/or glibc version but given the popularity of alpine for docker containers it would seem sensible for this one to be embedded too. Also, the more flavours that are added into native, the larger that jar becomes, which may be unpopular for some.
@benalexau What are your thoughts? wardle commented on Nov 18, 2025 Another option would be to have a sane set of default native libraries that are, by default, transitively included - a "set menu". This limits the size of the jar file and yet permits reasonable usage across a number of environments. If you are an expert user, or have specific requirements, one could use one's package manager (e.g maven) to exclude that transitive dependency and instead explicitly select a different set of native libraries (e.g. native-mac-arch64, native-linux-musl, native-linux-glibc-vXXX). That requires the native libraries to be built and available separately, and the default 'native' library to simply include a reasonable default set, but then allow users with specific requirements to choose the native libraries to include à la carte. That might satisfy broad applicability while empowering users to control what native libraries are bundled with their specific deployment. at055612 commented on Nov 18, 2025 I almost suggested this as back in 2022, this is how it was done I think (see maven), but feared if it would add more layers of complexity for the LJ maintainers.
Another option would be to use this (in TargetName.java)
/**
* Java system property name that can be set to override the embedded library that will be used.
* This is likely to be required if automatic resolution fails but the user still prefers to use
* an LmdbJava-bundled library. This path must include the classpath prefix (usually <code>
* org/lmdbjava/native</code>).
*/
public static final String LMDB_EMBEDDED_LIB_PROP = "lmdbjava.embedded.lib"; Rather than using maven/gradle dependency management to exclude/include, You could just embed the required lmdb lib in your own codebase and set this prop to use that.
Just tried this in a little LJ testbed app that I have. This has LJ as a dep. Dropped the alpine lib in src/main/resources/lmdbjavatestbed/liblmdb.so.0.0.0 then set the embedded prop accordingly
-Dlmdbjava.embedded.lib=lmdbjavatestbed/liblmdb.so.0.0.0. This gets it working in an alpine container.
I think this is a better solution than LJ having to maintain a long list of different compiled forms in maven. If you are building your app for multiple environments, then you can embed as many libs as you like in your own codebase and use the prop to choose at runtime. cdprete commented on Nov 18, 2025 ContributorAuthor More actions
I almost suggested this as back in 2022, this is how it was done I think (see maven), but feared if it would add more layers of complexity for the LJ maintainers.
Another option would be to use this (in TargetName.java)
/**
- Java system property name that can be set to override the embedded library that will be used.
- This is likely to be required if automatic resolution fails but the user still prefers to use
- an LmdbJava-bundled library. This path must include the classpath prefix (usually
org/lmdbjava/native).
*/
public static final String LMDB_EMBEDDED_LIB_PROP = "lmdbjava.embedded.lib";
Rather than using maven/gradle dependency management to exclude/include, You could just embed the required lmdb lib in your own codebase and set this prop to use that.
Just tried this in a little LJ testbed app that I have. This has LJ as a dep. Dropped the alpine lib in src/main/resources/lmdbjavatestbed/liblmdb.so.0.0.0 then set the embedded prop accordingly -Dlmdbjava.embedded.lib=lmdbjavatestbed/liblmdb.so.0.0.0. This gets it working in an alpine container.
I think this is a better solution than LJ having to maintain a long list of different compiled forms in maven. If you are building your app for multiple environments, then you can embed as many libs as you like in your own codebase and use the prop to choose at runtime.
Indeed it would work, but for the consumers this would require additional effort.
Also, depending on the environment you're in, the native library may not be available (in order to embed it) or to be outdated (see my previous screenshot).
Of course, as a consumer, I expect to have the minimum effort possible from my side when using a library.
On the other side, if I put myself in your position as maintainer, I see the struggle and your motivation towards moving such responsibility completely outside of LJ. bp-alex commented on Nov 19, 2025 I've addressed this in two commits:
Native library packaging (lmdbjava/native@5bf9d66):
Automatic detection (commit 8eb95d0):
- TargetName now detects musl vs glibc by checking /proc/self/maps
- Automatically selects the correct library variant
- Users can still override with lmdbjava.native.lib if needed
The latest snapshot should now work correctly on both Alpine (musl) and traditional (glibc) Linux systems.
Would you please test and confirm so that I can make a patch release? at055612 commented on Nov 20, 2025 Reacted by Cosimo Damiano Prete cdprete commented on Nov 23, 2025 ContributorAuthor More actions at055612 commented on Nov 25, 2025 @benalexau
I was looking into using zstd for something else and noticed that https://github.com/luben/zstd-jni has a similar issue to us in having to bundle platform specific native libraries. They appear to be using docker and QEMU emulation to build for each platform. Maven classifiers are used to specify the native lib to use with one classifier bundling a few common ones. I mention this in case it provides food for thought. bp-alex commented on Jan 13, 2026 I ended up implementing via lmdbjava/native@25bc8c6 what I foreshadowed in #280 (comment):
I suspect the best option is back to GitHub Actions on different VMs, collecting the compiled libraries after each build step, and bundling them all into a single JAR for Maven Central.
native 0.9.33-4 is now released using this new approach. Can we please try that version?
at055612 commented on Jan 23, 2026 @bp-alex I have just tested running 5061266 in an Alpine(musl) container and that is working fine, albeit for a very basic put/get test. Also working fine on my glibc based dev machine.
Thanks for making the changes to lmdbjava/native. 👍 cdprete commented on Jan 29, 2026 ContributorAuthor More actions
I ended up implementing via lmdbjava/native@25bc8c6 what I foreshadowed in #280 (comment):
I suspect the best option is back to GitHub Actions on different VMs, collecting the compiled libraries after each build step, and bundling them all into a single JAR for Maven Central.
native 0.9.33-4 is now released using this new approach. Can we please try that version?
@bp-alex should I test this as well on my RHEL 8.x instances or is it already expected it won't work? bp-alex commented on Jan 29, 2026 @cdprete I have changed LmdbJava Native to use a glibc 2.28-based container. It has been released in version 0.9.33-5. Can you please try that? Reacted by Cosimo Damiano Prete cdprete commented on Jan 30, 2026 ContributorAuthor More actions @bp-alex no errors so far with this new version.
No performance implications are expected from this new version, right? bp-alex commented on Feb 6, 2026 I have released LmdbJava 0.9.3 which includes LmdbJava Native 0.9.33-5. Reacted by Cosimo Damiano Prete cdprete commented on Feb 6, 2026 ContributorAuthor More actions Thank you 😊
Il ven 6 feb 2026, 04:23 Ben Alex ***@***.***> ha scritto:
…
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|
