FS#77183 - [jre17-openjdk] LD_LIBRARY_PATH causes UnsatisfiedLinkError: undefined symbol: reuseport_available

Attached to Project: Arch Linux
Opened by Sefa Eyeoglu (Scrumplex) - Thursday, 19 January 2023, 09:35 GMT
Last edited by Toolybird (Toolybird) - Sunday, 22 January 2023, 21:11 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Java fails to run when the following environment variable is present:

LD_LIBRARY_PATH=/usr/$LIB/

This started happening after the update to 17.0.6.u10-2.

While the environment variable above might seem redundant, it is set by mangohud and some other tools that integrate with mangohud so while a user might not set it, some other applications do.

Additional info:
* package version(s)
jre17-openjdk 17.0.6.u10-2
* config and/or log files etc.
* link to upstream bug report, if any

Steps to reproduce:

Full error:

Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-17-openjdk/lib/libnio.so: /usr/lib/jvm/java-17-openjdk/lib/libnio.so: undefined symbol: reuseport_available
at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388)
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232)
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174)
at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:315)
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:285)
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:270)
at java.base/jdk.internal.loader.BootLoader.loadLibrary(BootLoader.java:149)
at java.base/sun.nio.fs.UnixNativeDispatcher.<clinit>(UnixNativeDispatcher.java:667)
at java.base/sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:65)
at java.base/sun.nio.fs.LinuxFileSystem.<init>(LinuxFileSystem.java:39)
at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:46)
at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:39)
at java.base/sun.nio.fs.UnixFileSystemProvider.<init>(UnixFileSystemProvider.java:55)
at java.base/sun.nio.fs.LinuxFileSystemProvider.<init>(LinuxFileSystemProvider.java:41)
at java.base/sun.nio.fs.DefaultFileSystemProvider.<clinit>(DefaultFileSystemProvider.java:35)
at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:114)
at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:103)
at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:101)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:101)
at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.<clinit>(FileSystems.java:94)
at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:183)
at java.base/java.io.File.toPath(File.java:2387)
at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1264)
at java.base/java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:709)
at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:243)
at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:172)
at java.base/java.util.jar.JarFile.<init>(JarFile.java:347)
at java.base/java.util.jar.JarFile.<init>(JarFile.java:318)
at java.base/java.util.jar.JarFile.<init>(JarFile.java:257)
at java.base/sun.launcher.LauncherHelper.getMainClassFromJar(LauncherHelper.java:552)
at java.base/sun.launcher.LauncherHelper.loadMainClass(LauncherHelper.java:778)
at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:686)
This task depends upon

Closed by  Toolybird (Toolybird)
Sunday, 22 January 2023, 21:11 GMT
Reason for closing:  Not a bug
Additional comments about closing:  See comments
Comment by freswa (frederik) - Thursday, 19 January 2023, 12:50 GMT
reuseport_available is provided by /usr/lib/jvm/java-17-openjdk/lib/libnet.so. That lib is not in the LD_LIBRARY_PATH. Unfortunately the pkg libnet also provides /usr/lib/libnet.so, which is known to ld. Since we changed from rpath to runpath in binutils, binaries are now linked with runpath by default which has no precedence over LD_LIBRARY_PATH anymore.
Setting LD_LIBRARY_PATH causes ld to load /usr/lib/libnet.so which fails to have the needed symbols.

I do think that this behavior is correct and the error should be fixed by either not providing LD_LIBRARY_PATH to java or avoid using it at all.
Comment by Sefa Eyeoglu (Scrumplex) - Saturday, 21 January 2023, 11:26 GMT
I have created a comment for the mangohud AUR package to switch to a different library path to workaround this issue: https://aur.archlinux.org/packages/mangohud
Comment by Toolybird (Toolybird) - Sunday, 22 January 2023, 21:11 GMT
I agree with @freswa. Setting LD_LIBRARY_PATH like that just seems weird and wrong. Affected apps need to be fixed.

Loading...