|
|
Message-ID: <20170222215424.GA1153@jig.fritz.box>
Date: Wed, 22 Feb 2017 22:54:24 +0100
From: Mathias Krause <minipli@...glemail.com>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] musl-gcc.spec: honour $LIBRARY_PATH / $LPATH
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@...glemail.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
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.