Re: [PATCH] musl-gcc.spec: honour $LIBRARY_PATH / $LPATH

[Mathias Krause <minipli@googlemail.com>]

On Wed, Feb 22, 2017 at 04:11:58PM -0500, Rich Felker wrote:
> On Wed, Feb 22, 2017 at 09:57:05PM +0100, Mathias Krause wrote:
> > To support additional library search paths via $LIBRARY_PATH / $LPATH
> > extend the link_libgcc variable instead of replacing it. The original
> > one will contain the required "%D" to support this.
> > 
> > musl's library path is still the first in the list, so its object files
> > will be found before other paths are taken into account.
> > 
> > Signed-off-by: Mathias Krause <minipli@googlemail.com>
> > ---
> >  tools/musl-gcc.specs.sh |    4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/musl-gcc.specs.sh b/tools/musl-gcc.specs.sh
> > index 294e24f75503..819799a6d5a7 100644
> > --- a/tools/musl-gcc.specs.sh
> > +++ b/tools/musl-gcc.specs.sh
> > @@ -10,8 +10,10 @@ cat <<EOF
> >  *cc1:
> >  %(cc1_cpu) -nostdinc -isystem $incdir -isystem include%s
> >  
> > +%rename link_libgcc old_link_libgcc
> > +
> >  *link_libgcc:
> > --L$libdir -L .%s
> > +-L$libdir %(old_link_libgcc)
> 
> I'm pretty sure this is wrong. What are you trying to achieve?

I'm trying to make musl-gcc not break gcc's ability to search for
additional library paths via the LIBRARY_PATH environment variable.

Let me past the relevant section of gcc's manpage:

   LIBRARY_PATH
       The value of LIBRARY_PATH is a colon-separated list of
       directories, much like PATH.  When configured as a native
       compiler, GCC tries the directories thus specified when
       searching for special linker files, if it can't find them
       using GCC_EXEC_PREFIX.  Linking using GCC also uses these
       directories when searching for ordinary libraries for the
       -l option (but directories specified with -L come first).

I'm trying to make use of the "…when searching for ordinary libraries
for the -l option" part.

> The whole point of musl-gcc is to _remove_ any existing library paths
> since, if present, they will cause configure scripts to detect and
> link to incompatible libraries (linked against glibc).

Can you elaborate on this? How would including $LIBRARY_PATH provided
paths break configure scripts? In fact, the way the specs file is now
breaks my use case but I don't want to break yours. :/

> The only library path we want to preserve is the one to libgcc.

Well, the current spec file doesn't achieve this when LIBRARY_PATH is
set in the environment:

$ LIBRARY_PATH=/tmp /tmp/musl/bin/musl-gcc -x c -o /dev/null - <<<'int main(void) { }' -lgcc
/usr/bin/ld: cannot find -lgcc
collect2: error: ld returned 1 exit status
$ 

While with my patch applied it does:

$ LIBRARY_PATH=/tmp /tmp/musl/bin/musl-gcc -x c -o /dev/null - <<<'int main(void) { }' -lgcc
$ 


Cheers,
Mathias