mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Christopher Sean Morrison <>
Subject: [musl] dynamic linker is capturing "reserved" library names erroneously
Date: Wed, 27 Jul 2022 19:06:24 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 4766 bytes --]

The gist of this bug report / change request is best demonstrated by the following code setup:

$ cat >> librt.cpp
#include <stdio.h>
void foo(void) { printf("hello\n"); }
$ cat >> test.cpp
#include <stdio.h>
int main(int ac, char *av[]) { extern void foo(void); foo(); return 0; }
$ g++ -shared -o librt.cpp
$ g++ -o test test.cpp -L. -lrt -Wl,-rpath=.
$ ldd test
	/lib/ (0x7f35cf52a000) => /lib/ (0x7f35cf52a000) => /lib/ (0x7f35cf52a000)
Error relocating test: _Z3foov: symbol not found
$ ./test
Error relocating ./test: _Z3foov: symbol not found

In brief, ld appears to be capturing the resolution of librt as being satisfied by ld-musl-x86_64 at runtime despite the -L resolving correctly at compilation time (and rpath is ignored).  This naturally results in runtime symbol not found message(s) for any symbols in such a named library.  The offending code in musl appears to be <>

First consideration, the code seems to take a position that those library names are somehow universally reserved and I believe that to be incorrect.  There was mention of reserved lib names long ago specifically regarding the behavior of the “c89”  and “c99” C compiler CLI in their posix.1 man pages, but those did not carry over to prescribing dynamic library behavior, C++ behavior, or other any other aspects of the standard as far as I’m aware.  Perhaps a citation can be provided, but I was unable to find a relevant mention of ‘rt’, “librt”, “-lr”, etc, (or any of the other libs from line 1011) in the latest version of the standard.

Second consideration, the block’s preceding comment seems to document the primary intention as being to reduce app porting burden where -lm, -lc, and friends have long-since been embedded in build systems.  Given those libraries are all combined in musl’s libc implementation, that seems reasonable.  Automatically binding requests for -lm to musl’s libc, for example, certainly makes sense to ease porting.

Given those two considerations, I would suggest + request that the library resolution behavior be changed so that they are not captured reserved names but merely a fallback when normal searching would otherwise result in not-found.  That is, move the logic in dynlink.c so that it happens later, after typical searching as needed.  That way, the encoded rpath and libraries specified at link time will be respected, and build systems specifying -lm will still automatically resolve to musl’s libc (unless there really is a libm).

My expectation is that user applications should be able to specify any library name (even libc), link against it, and resolve to it at runtime as in the example above.  The gnu and bsd dynamic linkers do not make any presumption or restriction on library name resolution (at least not any more afaik), even with regards to auto-linking standard libraries.  Changing this behavior would also address a number of related reports I came across regarding this issue (e.g., search "error relocating" "symbol not found" musl <>).

For background context, I maintain BRL-CAD, a large open source CAD system that has been in development for over 40 years.  BRL-CAD’s flagship API with thousands of integrations around the world is the “librt” ray tracing library.  With dev going all the way back to 1983, it predates both ANSI C and POSIX.  Renaming isn’t likely anytime soon as it would be exceptionally cost-prohibitive and impacts so many other codes in production use.  We’ve maintained BRL-CAD’s portability across dozens of architectures, operating systems, and compilation environments over the years, and librt conflicts are not new.  What’s unique/novel here is musl’s runtime linker override behavior that hasn’t been seen for quite some time.  I found workarounds we can employ, but hopefully behavior can be improved to benefit future musl development.

Thank you for everyone’s efforts on an alternative to the established, and thank you for consideration of this issue.

Sean Morrsion

[-- Attachment #2: Type: text/html, Size: 9566 bytes --]

  reply	other threads:[~2022-07-27 23:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-27  6:28 [musl] sysconf(_SC_NPROCESSORS_CONF) broken Rob Landley
2022-07-27  6:34 ` [musl] " Rob Landley
2022-07-27 17:58   ` Szabolcs Nagy
2022-07-27 21:29     ` Jonathan Rajotte-Julien
2022-07-28 17:27       ` enh
2022-07-29 18:42         ` enh
2022-07-29 18:53           ` NRK
2022-07-29 19:39             ` enh
2022-07-27 18:05   ` enh
2022-07-27 23:06     ` Christopher Sean Morrison [this message]
2022-07-28  9:18       ` [musl] dynamic linker is capturing "reserved" library names erroneously Szabolcs Nagy
2022-07-28 20:39         ` Christopher Sean Morrison
2022-07-29  0:07           ` Rich Felker
2022-07-29  6:19             ` Christopher Sean Morrison

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).