[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 4 Aug 2016 13:09:54 -0500
From: "Sidney Manning" <sidneym@...eaurora.org>
To: <musl@...ts.openwall.com>
Subject: RE: relative link between libc.so and the dynamic linker
> -----Original Message-----
> From: Rich Felker [mailto:dalias@...ifal.cx] On Behalf Of Rich Felker
> Sent: Wednesday, August 03, 2016 9:19 PM
> To: musl@...ts.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
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.
