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.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2, URIBL_BLACK autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 22159 invoked from network); 17 Apr 2023 15:28:59 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 17 Apr 2023 15:28:59 -0000 Received: (qmail 3361 invoked by uid 550); 17 Apr 2023 15:28:53 -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 3329 invoked from network); 17 Apr 2023 15:28:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1681745321; i=nullplan@gmx.net; bh=cxD/pMCMt3ptBjCKUHZCYMxt88dnm0lQGxL01yIEhQk=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=KFM18E8+RWsymXx6SRtFyv5J0f8sqyWwK34xaMA2s1zgIPDRWZncBL+dY/J3wGKq6 5wxybRAEaFrv3WBkwLbq/a8CZutGafjHZZOeRCWOBtHCpuDQ1HVboKUFAbdmk5He/S fnD1KYajD3lJXz1/5P+yICIQA5GDOPwFOW/Fg0wPIQhsaewWzdl/yYfdEoR88f96/a ln5U6kZw9UQxnQR7WBeUW2aKhXVeRI3l5PgrHqF47OnnroAnVSf3/2YhD0AkKhDsGX A3ZLHnc60+KYReDExPDhL6xR2aArMcubABFHHp2gQdp1VMxUGf7s4PNP8FSVozRVZn S1+1CTTEt4JFw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Mon, 17 Apr 2023 17:28:39 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: References: <2584491.vYhyI6sBWr@workhack> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2584491.vYhyI6sBWr@workhack> X-Provags-ID: V03:K1:2k7G7nNyOAA9WVKqdIDZlS90PdaNr4WB6oV/8trrpkk5aQh600k nVrAhkeCZfV9XOPThkjH6yjPw5UfLEoXUNKNh3sLE2f3a5BxCYCdV1acfiCslkOVNrBDffM slVok9HP/S4QNTfAukC7C/Q4QG+dmFGjR9F37L7c+GGDnDYjjfVEFCN/eeaKduOW1oQZX+P c0zp0uhBp33m/UXeZJI9g== UI-OutboundReport: notjunk:1;M01:P0:uckiikJAV6c=;hNZONqOlv8/viuI4qIPi4GkmRnY RYHjWKWZSXhQi8NdF+u5LSRN2uJYkTBQWxt8D2EfPaC3fc/UjMwxMamNgJ4uEtjZBKe77L6gC sFb0rKXl2mAF9ODMcqlRsvOeJzEVwXvsTQbSvhJsF5yNn5wOL/ukdL9kVPINl3mRWerOgqSY6 tO+I1pieS8mAKz5oStGczI7FjrxiEDEyw83Umz0YNYNRANao2kO46O2vYijNdGVcaSUeuqI4/ n8HByT2G1zdCdHcI1NvALDUK8ZFQrie2aDwnB7QdXzAFGMiKf5H89/dn937z+m3ETK+CF5SvH Vwgjj0GLojJuPT2Z0Qk29nTVQqxq6PDcB/9EjK4rORyMongB3BTT5mwfIF3mSOya1N6PH8/6A f5PA9dHn57dOsK/KpWiBp831wUPiQoOcmcnjgtXf6giZHZpSGV0ooSEH8nq9Efjfs/YJlzj8U 44zwySmkkSEE4pCX2rYZFx6K8NxW/PLL1kU4eYR10Jwp1TPNCxMTw2cyJEczcTPMzI6n3Ojjk r5cl79GKzIK0wlepIHA6tUsmCd+nkQXHuqsA4ulPzp/V98qU8XU9BWK0T1rKn5dYG9ri1sDua zi5B1kA/5K7SLLI4wbJyVU8fAcBKYyksojnzoxHFgDzhkbnDcWd8Z0kMXclibDZbBgHYYR8py 18I9bal8Nu/R/t1RDgAn78Y8qPCqd29PoGZyK8kE7Lx1njhW2XAlfpbq2ACGuEsD52JVAz08j mJfyTw70zck1/5jdeW1YJZ8NcPyJpV/dy8Ekas2Q6oEZKhNSeRWQ0lbTrHi1TBrjB9/vbg/yV 3KRInGD63t83kk6GRwkAxAq4xiL26gAfbD7oK81F63+DsHUkJSMZmJnBeDNPcIwXvNPCpoQJ+ VCdC5JNMR8pL8H8q6yiATLgi+G9AAyrZUdKhpWBPpsbcXDy0NBR1X6PtvY7u2sVHOx3WjEv/6 SgyDsEtkiMImGGkMZYsT7GmuKzI= Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Add musl-ldd for user convenience and to avoid naming conflict Am Mon, Apr 17, 2023 at 04:36:24AM +0200 schrieb Lorenz Hipp: > --- a/ldso/dynlink.c 2022-04-07 19:12:40.000000000 +0200 > +++ b/ldso/dynlink.c 2023-04-16 20:40:15.960873385 +0200 > @@ -1791,7 +1791,15 @@ > int fd; > char *ldname =3D argv[0]; > size_t l =3D strlen(ldname); > - if (l >=3D 3 && !strcmp(ldname+l-3, "ldd")) ldd_mode =3D= 1; > + if (l =3D 3 && !strcmp(ldname, "ldd")) > + { > + ldd_mode =3D 1 ; > + } > + else > + if ( l =3D 8 && !strcmp(ldname, "musl-ldd")) > + { > + ldd_mode =3D 1 ; > + } > argv++; > while (argv[0] && argv[0][0]=3D=3D'-' && argv[0][1]=3D= =3D'-') { > char *opt =3D argv[0]+2; > First of all, this is erroneous, since l is being assigned a value. Not that it matters, because you are now doing full strcmp() of the string, so only an exact match works, and the value of l doesn't matter. Second, I fail to see what the point is. The old code enables ldd mode if argv[0] is at least 3 bytes long and ends in ldd, so it already recognizes musl-ldd. The new code, even if you fixed the erroneous assignments and changed them to comparisons, would work only if the ldd link was installed in some PATH directory, because now the comparisons only match exactly. That does not fit what you were describing further up. > Additionaly the Makefile would have to be adjusted, to create a > symbolic link at > > $(bindir)/musl-ldd -> $(libdir)/libc.so > Why does that need to be in the upstream Makefile? Can you not just put it in whatever install script you have? You are surely in the minority of people wanting a musl-ldd on the installed machine. Musl is often used in cross-compliation environments, and on such, the compiled code cannot be natively executed. Others use musl purely statically. Others still just call the dynamic linker directly, because some shells allow changing argv[0] without requiring weird symlinks. > Required patch : > > --- a/Makefile 2022-04-07 19:12:40.000000000 +0200 > +++ b/Makefile 2023-04-16 21:42:00.000000000 +0200 > @@ -219,6 +219,7 @@ > install-tools: $(ALL_TOOLS:obj/%=3D$(DESTDIR)$(bindir)/%) > > install: install-libs install-headers install-tools > + ln -sv $(libdir)/libc.so $(DESTDIR)$(bindir)/musl-ldd > > musl-git-%.tar.gz: .git > git --git-dir=3D$(srcdir)/.git archive --format=3Dtar.gz --pref= ix=3D$(patsubst %.tar.gz,%,$@)/ -o $@ $(patsubst musl-git-%.tar.gz,%,$@) And what about the people that don't want dynamic libs? They now get a dangling symlink as part of the distribution. > > > This way, the same musl build can be used on the development > machine where it has to co-exist at least with glibc and the > target machine, where musl is the standard (and only) linker. > > I have to admit, that the dynlink.c file could stay as it > is, because right now it accepts any program name, which > ends with "ldd". This might be intended behaviour. > > But at least for me, it would simply feel wrong and I > prefer source code, which is explicit about certain > things. > Feelings-based software engineering does not have a good track record. You cannot even articulate your objection to the current approach. > In that regard, the text in the FAQ might also be changed, > because > > Just create a symlink from ld-musl-$ARCH.so to /bin/ldd. > > would be more correctly > > Just create a symlink > /bin/ldd > pointing to > ld-musl-$ARCH.so. > > Because, for example, a link created as > > /usr/bin/paldd -> $(libdir)/libc.so > > would also work and I see no 'musl' in 'paldd', hence > my comment about software being explicit. > Still fail to see where the problem is. The proposed change may break someone's workflow for little reason, so why implement it? Ciao, Markus