[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160804021919.GE15995@brightrain.aerifal.cx>
Date: Wed, 3 Aug 2016 22:19:19 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: relative link between libc.so and the dynamic linker
On Wed, Aug 03, 2016 at 03:52:51PM -0500, Sidney Manning wrote:
> I'd like to suggest making the symbolic link between libc.so and
> ld-musl-<target>.so.1 relative rather than absolute. A relative path makes
> movement between systems easier, in particular when one is copying cross
> binaries to into a runtime environment.
Are you sure this is actually the case if you use DESTDIR rather than
prefix for staging the cross toolchain libs in the sysroot? I think
the current behavior already works fine as long as you do it that way,
but I may be mistaken.
> diff --git a/tools/install.sh b/tools/install.sh
> index d913b60..1c102f5 100755
> --- a/tools/install.sh
> +++ b/tools/install.sh
> @@ -48,7 +48,7 @@ trap 'rm -f "$tmp"' EXIT INT QUIT TERM HUP
> umask 077
>
> if test "$symlink" ; then
> -ln -s "$1" "$tmp"
> +ln -s -r "$1" "$tmp"
As Kylie noted, -r is not a standard option to ln. Also, if we do
decide to do something like this patch, the logic for the desired
relative path should be in the makefile rather than having install.sh
behave in ways that violate the principle of least surprise.
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.
