Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <04d401d1ee7b$67651180$362f3480$@codeaurora.org>
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.