Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

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


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


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/ /usr/lib/jvm/java-17-openjdk/lib/ undefined symbol: reuseport_available
at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
at java.base/jdk.internal.loader.NativeLibraries$
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(
at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(
at java.base/jdk.internal.loader.BootLoader.loadLibrary(
at java.base/sun.nio.fs.UnixNativeDispatcher.<clinit>(
at java.base/sun.nio.fs.UnixFileSystem.<init>(
at java.base/sun.nio.fs.LinuxFileSystem.<init>(
at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(
at java.base/sun.nio.fs.LinuxFileSystemProvider.newFileSystem(
at java.base/sun.nio.fs.UnixFileSystemProvider.<init>(
at java.base/sun.nio.fs.LinuxFileSystemProvider.<init>(
at java.base/sun.nio.fs.DefaultFileSystemProvider.<clinit>(
at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(
at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$
at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$
at java.base/
at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(
at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.<clinit>(
at java.base/java.nio.file.FileSystems.getDefault(
at java.base/
at java.base/$Source.get(
at java.base/$CleanableResource.<init>(
at java.base/<init>(
at java.base/<init>(
at java.base/java.util.jar.JarFile.<init>(
at java.base/java.util.jar.JarFile.<init>(
at java.base/java.util.jar.JarFile.<init>(
at java.base/sun.launcher.LauncherHelper.getMainClassFromJar(
at java.base/sun.launcher.LauncherHelper.loadMainClass(
at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(
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/ That lib is not in the LD_LIBRARY_PATH. Unfortunately the pkg libnet also provides /usr/lib/, 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/ 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:
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.