From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27793 invoked from network); 28 Jul 2022 09:18:44 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 28 Jul 2022 09:18:44 -0000 Received: (qmail 1213 invoked by uid 550); 28 Jul 2022 09:18:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1181 invoked from network); 28 Jul 2022 09:18:39 -0000 Date: Thu, 28 Jul 2022 11:18:27 +0200 From: Szabolcs Nagy To: Christopher Sean Morrison Cc: musl@lists.openwall.com Message-ID: <20220728091827.GD1320090@port70.net> Mail-Followup-To: Christopher Sean Morrison , musl@lists.openwall.com References: <43e9ad2b-d53c-5fd5-0211-766f946c90f9@landley.net> <48546934-5ccd-0b1e-bf2b-306133101c6b@landley.net> <03A11083-A7D8-409E-BA70-AC42F52FF7B2@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <03A11083-A7D8-409E-BA70-AC42F52FF7B2@mac.com> Subject: Re: [musl] dynamic linker is capturing "reserved" library names erroneously * 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. 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 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 syste= m that has been in development for over 40 years. > BRL-CAD=E2=80=99s flagship API with thousands of integrations around the = world is the =E2=80=9Clibrt=E2=80=9D 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).