|
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.