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

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

[Mathias Krause]

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)
 
 *libgcc:
 libgcc.a%s %:if-exists(libgcc_eh.a%s)
-- 
1.7.10.4

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

[Rich Felker]

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? 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). The only
library path we want to preserve is the one to libgcc.

Rich

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

[Mathias Krause]

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

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

[Rich Felker]

On Wed, Feb 22, 2017 at 10:54:24PM +0100, Mathias Krause wrote:
> 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. :/

It's not that $LIBRARY_PATH breaks it, but rather that the defaults
copied from the original link_libgcc might break it. If you think this
is wrong, please check; it's been a long time since I looked at this.

Rich