[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170222211158.GU1520@brightrain.aerifal.cx>
Date: Wed, 22 Feb 2017 16:11:58 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] musl-gcc.spec: honour $LIBRARY_PATH / $LPATH
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? 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
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.
