From mboxrd@z Thu Jan  1 00:00:00 1970
From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Subject: Re: Phase `validate-runpath' fails: lib not in RUNPATH
Date: Mon, 07 Nov 2016 10:03:57 +0100
Message-ID: <87wpgfwtj6.fsf@gnu.org>
References: <10612b67-4c72-1178-46a8-3a79572f3cde@crazy-compilers.com>
	<87twbk8l2j.fsf@elephly.net>
	<d7652b40-56d8-63be-e600-58c2d0209d41@crazy-compilers.com>
	<20161106213439.6010e115@scratchpost.org> <87y40wht5n.fsf@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Return-path: <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:37998)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1c3fqY-0002gY-Oa
	for guix-devel@gnu.org; Mon, 07 Nov 2016 04:04:07 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1c3fqT-0001vO-VJ
	for guix-devel@gnu.org; Mon, 07 Nov 2016 04:04:06 -0500
In-Reply-To: <87y40wht5n.fsf@gmail.com> (Chris Marusich's message of "Sun, 06
	Nov 2016 19:21:08 -0800")
List-Id: "Development of GNU Guix and the GNU System distribution."
	<guix-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/guix-devel/>
List-Post: <mailto:guix-devel@gnu.org>
List-Help: <mailto:guix-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=subscribe>
Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org
Sender: "Guix-devel" <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
To: Chris Marusich <cmmarusich@gmail.com>
Cc: Guix-devel <guix-devel@gnu.org>

Chris Marusich <cmmarusich@gmail.com> skribis:

> Danny Milosavljevic <dannym@scratchpost.org> writes:
>
>> On Sun, 6 Nov 2016 20:52:20 +0100
>> Hartmut Goebel <h.goebel@crazy-compilers.com> 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?

Specifically, the =E2=80=98ld=E2=80=99 wrapper (in gnu/packages/ld-wrapper.=
in) arranges
to add a -Wl,-rpath flag for each -l flag that it sees.

However, the =E2=80=98ld=E2=80=99 wrapper does not add such a flag if there=
=E2=80=99s no
corresponding -l flag, or if Thunderbird somehow managed to bypass the
wrapper altogether.

I=E2=80=99d suggest checking the link command line for the offending .so in
Thunderbird to see exactly what=E2=80=99s going on.  It might just be that =
it
misses -lnspr4 or something like that.

HTH,
Ludo=E2=80=99.