From: Szabolcs Nagy <firstname.lastname@example.org>
To: Christopher Sean Morrison <email@example.com>
Subject: Re: [musl] dynamic linker is capturing "reserved" library names erroneously
Date: Thu, 28 Jul 2022 11:18:27 +0200 [thread overview]
Message-ID: <20220728091827.GD1320090@port70.net> (raw)
* Christopher Sean Morrison <firstname.lastname@example.org> [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.
the way libraries are looked up is not specified in detail and
the standard gives the permission to implementations to decide.
some library names are special, but in conforming environment
this is only observable via the c99 tool so that's where this
is specified, the language does not know anything about libraries.
one exception is dlopen which has
If file contains a <slash> character, the file argument is used
as the pathname for the file. Otherwise, file is used in an
implementation-defined manner to yield a pathname.
so if you want reliable behaviour you need a path with /
e.g. in your example ./librt.so would have worked fine.
i believe the reason musl has to special case the names in ld.so
is to be able to load libraries linked against glibc. another
reason is to support looking up symbols in librt etc via dlsym.
> 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.
this would not work eg on older glibc if one of your dependencies
used clock_gettime. there is a reason why the c99 tool spec says
that the behaviour is unspecified if you have another librt in the
lookup path, this is a fragile setup.
i think if you want to avoid porting work then you should fix this
name collision on your side.
of course musl can also be fixed to be more friendly to such usage,
but it's not obvious how to tell if a librt.so is a user library or
part of libc (or glibc in case glibc abi compat is used).
next prev parent reply other threads:[~2022-07-28 9:18 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 [this message]
2022-07-28 20:39 ` Christopher Sean Morrison
2022-07-29 0:07 ` Rich Felker
2022-07-29 6:19 ` Christopher Sean Morrison
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).