Re: musl vs. Debian policy

[Rich Felker <dalias@aerifal.cx>]

On Fri, Mar 08, 2013 at 04:13:59PM +0100, Christian Neukirchen wrote:
> >> In this case, could we also change the SONAME of the library itself to
> >> something not libc.so?  It would avoid this "bogus" warning of glibc
> >> ldconfig...
> >
> > No, this is a lot more problematic and I see no benefits. For each
> > possible SONAME musl may have been linked by, musl must contain a
> > special-case to refuse to load this SONAME when it appears in
> > DT_NEEDED. "libc.so" is a name that should never appear elsewhere. I
> > don't want to keep expanding this list of names, and of course
> > programs linked using a new SONAME would be gratuitously incompatible
> > with an older musl ld.so that didn't have the new name included in its
> > refuse-to-load list.
> 
> ld-musl-x86_64.so shouldn't appear elsewhere either.

Yes and no. Formally, libc.so is in a sort of reserved namespace (or
at least, -lc is), whereas there's nothing "reserved" about the name
ld-musl-$(ARCH).so.1. I agree this is fairly irrelevant however as
nobody else is going to use that library name unless they're trying to
break things.

> >> ldconfig: /usr/lib/libc.so is not a symbolic link
> >
> > IIRC this is happening due to some other misconfiguration. If nothing
> > else, it means glibc and musl were both installed in /usr/lib, or
> > ldconfig is configured for the wrong paths (since ldconfig has nothing
> > to do with musl).
> 
> This happens because /lib/ld-musl-x86_64.so.1 has a SONAME of libc.so
> (which should be the correct place).  The message is not harmful, but
> annoying.

Well the message should never happen unless ldconfig is processing the
directory containing libc.so, right? It doesn't happen for me on
Debian when I have musl's ld-musl-i386.so.1 in /lib and ldconfig
processes the default library path.

Rich