[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 17 Apr 2023 17:28:39 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: 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 = argv[0];
> size_t l = strlen(ldname);
> - if (l >= 3 && !strcmp(ldname+l-3, "ldd")) ldd_mode = 1;
> + if (l = 3 && !strcmp(ldname, "ldd"))
> + {
> + ldd_mode = 1 ;
> + }
> + else
> + if ( l = 8 && !strcmp(ldname, "musl-ldd"))
> + {
> + ldd_mode = 1 ;
> + }
> argv++;
> while (argv[0] && argv[0][0]=='-' && argv[0][1]=='-') {
> char *opt = 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/%=$(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=$(srcdir)/.git archive --format=tar.gz --prefix=$(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/<whatever>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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
