* relative link between libc.so and the dynamic linker
@ 2016-08-03 20:52 Sidney Manning
2016-08-03 21:14 ` Kylie McClain
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Sidney Manning @ 2016-08-03 20:52 UTC (permalink / raw)
To: musl
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.
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"
else
cat < "$1" > "$tmp"
chmod "$mode" "$tmp"
The final result would look something like this:
ld-musl-x86_64.so.1 -> ../usr/lib/libc.so
Rather than:
ld-musl-x86_64.so.1 -> /tmp/musl/install/usr/lib/libc.so
Thanks,
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: relative link between libc.so and the dynamic linker
2016-08-03 20:52 relative link between libc.so and the dynamic linker Sidney Manning
@ 2016-08-03 21:14 ` Kylie McClain
2016-08-04 2:19 ` Rich Felker
2016-08-04 7:49 ` Khem Raj
2 siblings, 0 replies; 6+ messages in thread
From: Kylie McClain @ 2016-08-03 21:14 UTC (permalink / raw)
To: musl
On Wed, Aug 3, 2016 at 4:52 PM, Sidney Manning <sidneym@codeaurora.org> 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.
>
> 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"
This would introduce a dependency on a non-standard GNUism in the
coreutils ln implementation.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: relative link between libc.so and the dynamic linker
2016-08-03 20:52 relative link between libc.so and the dynamic linker Sidney Manning
2016-08-03 21:14 ` Kylie McClain
@ 2016-08-04 2:19 ` Rich Felker
2016-08-04 18:09 ` Sidney Manning
2016-08-04 7:49 ` Khem Raj
2 siblings, 1 reply; 6+ messages in thread
From: Rich Felker @ 2016-08-04 2:19 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: relative link between libc.so and the dynamic linker
2016-08-03 20:52 relative link between libc.so and the dynamic linker Sidney Manning
2016-08-03 21:14 ` Kylie McClain
2016-08-04 2:19 ` Rich Felker
@ 2016-08-04 7:49 ` Khem Raj
2016-08-04 16:47 ` Rich Felker
2 siblings, 1 reply; 6+ messages in thread
From: Khem Raj @ 2016-08-04 7:49 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 978 bytes --]
> On Aug 3, 2016, at 1:52 PM, Sidney Manning <sidneym@codeaurora.org> 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.
>
> 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"
> else
> cat < "$1" > "$tmp"
> chmod "$mode" "$tmp"
>
>
>
> The final result would look something like this:
> ld-musl-x86_64.so.1 -> ../usr/lib/libc.so
>
> Rather than:
> ld-musl-x86_64.so.1 -> /tmp/musl/install/usr/lib/libc.so
Does something like this help you
https://github.com/kraj/musl/commit/c0b1bd4e6bb60b8167e1f4a40beccff7f8871691
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 204 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: relative link between libc.so and the dynamic linker
2016-08-04 7:49 ` Khem Raj
@ 2016-08-04 16:47 ` Rich Felker
0 siblings, 0 replies; 6+ messages in thread
From: Rich Felker @ 2016-08-04 16:47 UTC (permalink / raw)
To: musl
On Thu, Aug 04, 2016 at 12:49:57AM -0700, Khem Raj wrote:
>
> > On Aug 3, 2016, at 1:52 PM, Sidney Manning <sidneym@codeaurora.org> 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.
> >
> > 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"
> > else
> > cat < "$1" > "$tmp"
> > chmod "$mode" "$tmp"
> >
> >
> >
> > The final result would look something like this:
> > ld-musl-x86_64.so.1 -> ../usr/lib/libc.so
> >
> > Rather than:
> > ld-musl-x86_64.so.1 -> /tmp/musl/install/usr/lib/libc.so
>
> Does something like this help you
>
> https://github.com/kraj/musl/commit/c0b1bd4e6bb60b8167e1f4a40beccff7f8871691
This assumes that one level of .. gets you from $(libdir) to /. For a
normal setup with libdir=/usr/lib that's not going to be the case,
though of course lots of people these days like omitting /usr or
making it a symlink to /, in which case it will work.
Rich
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: relative link between libc.so and the dynamic linker
2016-08-04 2:19 ` Rich Felker
@ 2016-08-04 18:09 ` Sidney Manning
0 siblings, 0 replies; 6+ messages in thread
From: Sidney Manning @ 2016-08-04 18:09 UTC (permalink / raw)
To: musl
> -----Original Message-----
> From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
> Sent: Wednesday, August 03, 2016 9:19 PM
> To: musl@lists.openwall.com
> Subject: Re: [musl] 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.
>
Yes, DESTDIR will work for me. So for cross builds, setting
prefix/libdir/syslibdir to target relative locations and DESTDIR to the
location of the image root works in the way I wanted it to.
This might not be relevant for very many people but for those that nfs mount
their freshly built c-library for a runtime check would still see ld-musl
pointing the wrong libc.so until they chrooted.
Thanks,
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-08-04 18:09 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-03 20:52 relative link between libc.so and the dynamic linker Sidney Manning
2016-08-03 21:14 ` Kylie McClain
2016-08-04 2:19 ` Rich Felker
2016-08-04 18:09 ` Sidney Manning
2016-08-04 7:49 ` Khem Raj
2016-08-04 16:47 ` Rich Felker
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).