From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Phase `validate-runpath' fails: lib not in RUNPATH Date: Sun, 06 Nov 2016 19:21:08 -0800 Message-ID: <87y40wht5n.fsf@gmail.com> References: <10612b67-4c72-1178-46a8-3a79572f3cde@crazy-compilers.com> <87twbk8l2j.fsf@elephly.net> <20161106213439.6010e115@scratchpost.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3acO-0003vs-Hm for guix-devel@gnu.org; Sun, 06 Nov 2016 22:29:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c3acN-00043p-Km for guix-devel@gnu.org; Sun, 06 Nov 2016 22:29:08 -0500 Received: from mail-pf0-x22f.google.com ([2607:f8b0:400e:c00::22f]:35780) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c3acN-00043G-E9 for guix-devel@gnu.org; Sun, 06 Nov 2016 22:29:07 -0500 Received: by mail-pf0-x22f.google.com with SMTP id i88so83377010pfk.2 for ; Sun, 06 Nov 2016 19:29:07 -0800 (PST) In-Reply-To: <20161106213439.6010e115@scratchpost.org> (Danny Milosavljevic's message of "Sun, 6 Nov 2016 21:34:39 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Danny Milosavljevic Cc: Guix-devel --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Danny Milosavljevic writes: > On Sun, 6 Nov 2016 20:52:20 +0100 > Hartmut Goebel wrote: >> Thanks for this tip. I'm cuprous, though . Both "libplds4.so" and >> "libnspr4.so" are part of "nspr" which is specified as input. > > Yes, but will the linker embed the full path to libnspr4.so into the > executable (or in your case shared library) it builds for thunderbird? > If not, ld.so would pick up a random package at runtime (one it just > happens to find in the library search path) - something we don't want. > > What the ld option "rpath" does is embed the full path to libnspr4.so > into the executable (or in this case shared object) it builds. In this > way it will pick exactly this libnspr4.so library or fail at startup. I thought the default gnu build system arranges for the rpath to be set correctly in the executables? Why would we need to add code here to do that for this one package? I thought it would happen automatically. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYH/MkAAoJEN1AmhXYIkadTzsP+wQs0xNSfRKz0hQLX51mAF1O /8suOZOdZLs+COs+3ODIGo5SoykpuFIWvEUGG4IBrKzt7krPCzIsphULGvJDtilF /5Md2GGG5TBmcyKE/XC5IKPc2UTG1R4CH0LokYkkIQ87ctUujkoH12MFqkbqIGNO wlN+eMy6o4fOkLhRHZWs5k5HTp4hw7ohgknKfMJ1PkoOkZSoCpQ+FwLyzfOFWzEp BFW9aV6XcwyaS4U5R0CJzRhVeULjZLgqDzIEOG5t5Q208+OPFvoWJ9ORcIqtAsr4 oWoRKZ3PcKCv3EkJ90HXd4QphftVKTASgtl6AD375gt2F3FXclg2WKsAWw1i+mTn zukMOwZfCEVjrDn6id+geN9pZLnuJ4/SKApKNSzaEQHoh94+Tv114IiqeL7bm6Oj xCvQMThjpTk+401aScN+nYzxIbiGtzrmpUrGa5fKljNGhL3L/0YppOlC4gPJVMA6 Ul9/l96b9X8tPNk72Eq0TQI3reMQAEM6d9raLjQH1qPDB1UpUfqZac3FcRiBZSCf 8mYQ5skds0kPppdSWqHC1cEGPbhoA97H+f39h6Z63FHcW9ljipyrekOKiUImLw2h kteubjFNVkemCr1/D0HoHj5GbqOxSEInknLO6yYCpL3eEH4erqRVeufTBtY3KvTr /JptEX5yk/GdUQJW1Xzo =j8P0 -----END PGP SIGNATURE----- --=-=-=--