mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <>
To: Christopher Sean Morrison <>
Subject: Re: [musl] dynamic linker is capturing "reserved" library names erroneously
Date: Thu, 28 Jul 2022 20:07:36 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Jul 28, 2022 at 04:39:07PM -0400, Christopher Sean Morrison wrote:
> > On Jul 28, 2022, at 5:18 AM, Szabolcs Nagy <> wrote:
> > 
> > * Christopher Sean Morrison <> [2022-07-27 19:06:24 -0400]:
> >> First consideration, the code seems to take a position that those
> >> library names are somehow universally reserved and I believe that
> >> to be incorrect.

As others have noted, the behavior of -lrt is defined as linking the
standard library for realtime interfaces, not a user-defined library
by that name. The specification goes so far as to say, regarding use
of -L to try to override that:

  If a directory specified by a -L option contains files with names
  starting with any of the strings "libc.", "libl.", "libpthread.",
  "libm.", "librt.", "libtrace.", "libxnet.", or "liby.", the results
  are unspecified.

You may think it seems like it should be okay to use the name "librt"
if you're not linking the standard -lrt, but imagine what would happen
if you were on an implementation where some of the standard functions
were defined in a discrete rather than all integrated in like musl does: any *other* library that got pulled in
(possibly even one of the standard ones) that depends on librt would
end up getting that DT_NEEDED reference resolved to your library by
the same name, rather than to the standard one, and you would end up
with runtime link errors resolving the missing symbols.

I'm really surprised you haven't run into any problems with this clash
before. Surely I'd think someone would have tried to use clock_gettime
(the only modern way to get the current system clock time) in a
program that also needs to use your library, and on many historical
implementations, including glibc up until recently, you couldn't get
clock_gettime without -lrt (this the horrible syscall() hacks all over
the place to use the syscall directly).

> > i believe the reason musl has to special case the names in
> > is to be able to load libraries linked against glibc. another
> > reason is to support looking up symbols in librt etc via dlsym.
> That is why I proposed a solution of deferring the capture until
> after searching, so it will both satisfy that desire to resolve
> symbols for when -lm, -lr, -lpthread, etc are specified while also
> supporting the general case where such libraries actually do exist
> and are intended to be used.

This would cause very bad things to happen if someone copied the glibc
versions of those libraries around with a glibc-linked program they
were trying to use with ABI-compat, not aware that they were actually
part of glibc and not third-party libraries the application needed.

There is something of a long-term direction to decouple the ABI-compat
stuff from musl, and I'm not sure if it would make sense to unreserve
the names at the same time. A proposal to do this, like any proposal
for supporting nonstandard functionality that could have unforseen
consequences, would need to involve research into what those
consequences might be, if any. It might end up being okay to do
something like first hardening protection against loading glibc-linked
libraries by those names (assuming they're the corresponding parts of
the standard library from glibc) and then doing like you said, only
using them as fallbacks after search.


  reply	other threads:[~2022-07-29  0:07 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     ` [musl] dynamic linker is capturing "reserved" library names erroneously Christopher Sean Morrison
2022-07-28  9:18       ` Szabolcs Nagy
2022-07-28 20:39         ` Christopher Sean Morrison
2022-07-29  0:07           ` Rich Felker [this message]
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).