musl - Satisfying DT_NEEDED from previous full path dlopens

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1755910727.129cb9cinf.none@localhost>
Date: Fri, 22 Aug 2025 21:23:31 -0400
From: "Alex Xu (Hello71)" <alex_y_xu@...oo.ca>
To: musl@...ts.openwall.com
Subject: Satisfying DT_NEEDED from previous full path dlopens

Hi,

Previously, I posted https://www.openwall.com/lists/musl/2021/12/16/1 
about this issue. As this is still an issue, I would like to re-raise 
and summarize it.

Problem: With musl, if an application calls dlopen("/app/lib1.so"); 
dlopen("/app/lib2.so"), where lib2.so has DT_NEEDED: lib1.so, the second 
dlopen will fail. glibc, FreeBSD, NetBSD, OpenBSD, and possibly 
Haiku will match the dependency by DT_SONAME. Windows will match by 
filename, and macOS will match by dylib ID.

Julia, OpenJDK, and Wine rely on this behavior.

Solutions:

1. Julia can't use DT_RPATH or DT_RUNPATH with $ORIGIN-relative paths 
   because the relative path contains the version number of lib2 which 
   is not known at compile time.

2. LD_LIBRARY_PATH requires a wrapper or re-exec, but Julia may be 
   embedded in another app which makes both inconvenient.

3. lib2 can be linked without lib1, but this is semantically wrong and 
   causes unclear error messages if lib1 is not loaded or a wrong version 
   is loaded.

4. The simplest solution is to allow DT_NEEDED to match DT_SONAME of 
   previous loaded libraries, matching other libcs.

Thanks,
Alex.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.