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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16029 invoked from network); 27 Jul 2022 23:06:41 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 27 Jul 2022 23:06:41 -0000 Received: (qmail 29844 invoked by uid 550); 27 Jul 2022 23:06:38 -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 29808 invoked from network); 27 Jul 2022 23:06:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mac.com; s=1a1hai; t=1658963185; bh=uOn6D+tgkuRcISD5AkBQFb0+iq3cLBS6c3/JDlh58wk=; h=From:Content-Type:Mime-Version:Subject:Date:To:Message-Id; b=u/NFgR6bLtccIspmDs6yxQYDT8A3QfanoXonz2pvQyHpzGbscUYI/fvCik93N8t1C U8pJ2HcXNq/enyQ0I4XRb6VudZjNcK5NQJdOK/oQI05iZIeWTFVD55Mo40v/BsmI65 yEwoqzBib+1IGBuaT7FpR7UXZmxmZ3PS9wATHa/tCl6d6qkDm6TOyCsQoL7cI+D6FW D2o0STIGV+GmkwOKZaMI/QqPrRSFx5BMuXhY5X0Ka/Ehi6/wix7qUyx/XXRqQ51TPh XAe9/2rhU0lVoME3WVjCQYY/wHsFFyWR4bKvdIwrIAlE0QtCJkj4KRbGs5b7CU1xkh gGPNTZ4mrK+3g== From: Christopher Sean Morrison Content-Type: multipart/alternative; boundary="Apple-Mail=_4404C435-1D70-45E4-9C42-FF39AE39C7CC" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Wed, 27 Jul 2022 19:06:24 -0400 References: <43e9ad2b-d53c-5fd5-0211-766f946c90f9@landley.net> <48546934-5ccd-0b1e-bf2b-306133101c6b@landley.net> To: musl@lists.openwall.com In-Reply-To: Message-Id: <03A11083-A7D8-409E-BA70-AC42F52FF7B2@mac.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Proofpoint-GUID: Ci_4yaE8zO6rlXbq2CavP0c32XTiRaw0 X-Proofpoint-ORIG-GUID: Ci_4yaE8zO6rlXbq2CavP0c32XTiRaw0 X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.138,18.0.790,17.11.62.513.0000000_definitions?= =?UTF-8?Q?=3D2022-01-12=5F02:2020-02-14=5F02,2022-01-12=5F02,2021-12-02?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 adultscore=0 suspectscore=0 clxscore=1011 spamscore=0 bulkscore=0 malwarescore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207270103 Subject: [musl] dynamic linker is capturing "reserved" library names erroneously --Apple-Mail=_4404C435-1D70-45E4-9C42-FF39AE39C7CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The gist of this bug report / change request is best demonstrated by the = following code setup: $ cat >> librt.cpp #include void foo(void) { printf("hello\n"); } $ cat >> test.cpp #include int main(int ac, char *av[]) { extern void foo(void); foo(); return 0; } $ g++ -shared -o librt.so librt.cpp $ g++ -o test test.cpp -L. -lrt -Wl,-rpath=3D. $ ldd test /lib/ld-musl-x86_64.so.1 (0x7f35cf52a000) librt.so =3D> /lib/ld-musl-x86_64.so.1 (0x7f35cf52a000) libc.musl-x86_64.so.1 =3D> /lib/ld-musl-x86_64.so.1 = (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 = https://git.musl-libc.org/cgit/musl/tree/ldso/dynlink.c#n1011 = 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 =E2=80=9Cc89=E2=80=9D and = =E2=80=9Cc99=E2=80=9D 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=E2=80=99m= aware. Perhaps a citation can be provided, but I was unable to find a = relevant mention of =E2=80=98rt=E2=80=99, =E2=80=9Clibrt=E2=80=9D, = =E2=80=9C-lr=E2=80=9D, etc, (or any of the other libs from line 1011) in = the latest version of the standard. Second consideration, the block=E2=80=99s 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=E2=80=99s libc = implementation, that seems reasonable. Automatically binding requests = for -lm to musl=E2=80=99s 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=E2=80=99s 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=E2=80=99s = flagship API with thousands of integrations around the world is the = =E2=80=9Clibrt=E2=80=9D ray tracing library. With dev going all the way = back to 1983, it predates both ANSI C and POSIX. Renaming isn=E2=80=99t = likely anytime soon as it would be exceptionally cost-prohibitive and = impacts so many other codes in production use. We=E2=80=99ve maintained = BRL-CAD=E2=80=99s portability across dozens of architectures, operating = systems, and compilation environments over the years, and librt = conflicts are not new. What=E2=80=99s unique/novel here is musl=E2=80=99s= runtime linker override behavior that hasn=E2=80=99t 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=E2=80=99s efforts on an alternative to the = established, and thank you for consideration of this issue. Cheers! Sean Morrsion BRL-CAD --Apple-Mail=_4404C435-1D70-45E4-9C42-FF39AE39C7CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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.so librt.cpp
$ g++ = -o test test.cpp -L. -lrt -Wl,-rpath=3D.
$ = ldd test
= /lib/ld-musl-x86_64.so.1 (0x7f35cf52a000)
= librt.so =3D> /lib/ld-musl-x86_64.so.1 = (0x7f35cf52a000)
= libc.musl-x86_64.so.1 =3D> /lib/ld-musl-x86_64.so.1 = (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 https://git.musl-libc.org/cgit/musl/tree/ldso/dynlink.c#n1011

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 =E2=80=9Cc89=E2=80=9D =  and =E2=80=9Cc99=E2=80=9D 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=E2=80=99m aware.  Perhaps a citation can be provided, but = I was unable to find a relevant mention of =E2=80=98rt=E2=80=99, = =E2=80=9Clibrt=E2=80=9D, =E2=80=9C-lr=E2=80=9D, etc, (or any of the = other libs from line 1011) in the latest version of the = standard.

Second= consideration, the block=E2=80=99s 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=E2=80=99s libc = implementation, that seems reasonable.  Automatically binding = requests for -lm to musl=E2=80=99s 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=E2=80=99s 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=E2=80=99s flagship API with thousands of integrations = around the world is the =E2=80=9Clibrt=E2=80=9D ray tracing library. =  With dev going all the way back to 1983, it predates both ANSI C and POSIX.  Renaming isn=E2=80= =99t likely anytime soon as it would be exceptionally cost-prohibitive = and impacts so many other codes in production use. =  We=E2=80=99ve maintained BRL-CAD=E2=80=99s portability = across dozens of architectures, operating systems, and compilation = environments over the years, and librt conflicts are not new. =  What=E2=80=99s unique/novel here is musl=E2=80=99s runtime linker = override behavior that hasn=E2=80=99t 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=E2=80=99s = efforts on an alternative to the established, and thank you for = consideration of this issue.

Cheers!
Sean = Morrsion
BRL-CAD

= --Apple-Mail=_4404C435-1D70-45E4-9C42-FF39AE39C7CC--