* Phase `validate-runpath' fails: lib not in RUNPATH
@ 2016-11-06 18:11 Hartmut Goebel
2016-11-06 19:28 ` Ricardo Wurmus
0 siblings, 1 reply; 6+ messages in thread
From: Hartmut Goebel @ 2016-11-06 18:11 UTC (permalink / raw
To: Guix-devel
Hi,
I'm trying to build thunderbird ATM, modelled after the build for icecat.
Phase `validate-runpath' fails with errors like this:
/gnu/store/…-thunderbird-45.4.0/lib/firefox-45.4.1/browser/components/libbrowsercomps.so:
error: depends on 'libplds4.so', which cannot be found in RUNPATH
/gnu/store/…-thunderbird-45.4.0/lib/firefox-devel-45.4.1/sdk/lib/libxul.so:
error: depends on 'libnspr4.so', which cannot be found in RUNPATH
Any hint what this can be caused by?
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goebel@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Phase `validate-runpath' fails: lib not in RUNPATH
2016-11-06 18:11 Phase `validate-runpath' fails: lib not in RUNPATH Hartmut Goebel
@ 2016-11-06 19:28 ` Ricardo Wurmus
2016-11-06 19:52 ` Hartmut Goebel
0 siblings, 1 reply; 6+ messages in thread
From: Ricardo Wurmus @ 2016-11-06 19:28 UTC (permalink / raw
To: Hartmut Goebel; +Cc: Guix-devel
Hartmut Goebel <h.goebel@crazy-compilers.com> writes:
> I'm trying to build thunderbird ATM, modelled after the build for icecat.
>
> Phase `validate-runpath' fails with errors like this:
>
> /gnu/store/…-thunderbird-45.4.0/lib/firefox-45.4.1/browser/components/libbrowsercomps.so:
> error: depends on 'libplds4.so', which cannot be found in RUNPATH
>
> /gnu/store/…-thunderbird-45.4.0/lib/firefox-devel-45.4.1/sdk/lib/libxul.so:
> error: depends on 'libnspr4.so', which cannot be found in RUNPATH
>
> Any hint what this can be caused by?
This happens when libraries are referenced that are not in the default
library location of this package’s output directory.
In the package for R we have a similar situation and fix it by passing
these make flags:
#:make-flags
(list (string-append "LDFLAGS=-Wl,-rpath="
(assoc-ref %outputs "out")
"/lib/R/lib"))
This adds the “/lib/R/lib” directory to the RUNPATH, so that references
to these libraries can be properly embedded.
~~ Ricardo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Phase `validate-runpath' fails: lib not in RUNPATH
2016-11-06 19:28 ` Ricardo Wurmus
@ 2016-11-06 19:52 ` Hartmut Goebel
2016-11-06 20:34 ` Danny Milosavljevic
0 siblings, 1 reply; 6+ messages in thread
From: Hartmut Goebel @ 2016-11-06 19:52 UTC (permalink / raw
To: Ricardo Wurmus; +Cc: Guix-devel
Am 06.11.2016 um 20:28 schrieb Ricardo Wurmus:
> Hartmut Goebel <h.goebel@crazy-compilers.com> writes:
>
>> /gnu/store/…-thunderbird-45.4.0/lib/firefox-45.4.1/browser/components/libbrowsercomps.so:
>> error: depends on 'libplds4.so', which cannot be found in RUNPATH
>>
>> /gnu/store/…-thunderbird-45.4.0/lib/firefox-devel-45.4.1/sdk/lib/libxul.so:
>> error: depends on 'libnspr4.so', which cannot be found in RUNPATH
> #:make-flags
> (list (string-append "LDFLAGS=-Wl,-rpath="
> (assoc-ref %outputs "out")
> "/lib/R/lib"))
>
> This adds the “/lib/R/lib” directory to the RUNPATH, so that references
> to these libraries can be properly embedded.
Thanks for this tip. I'm cuprous, though . Both "libplds4.so" and
"libnspr4.so" are part of "nspr" which is specified as input.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goebel@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Phase `validate-runpath' fails: lib not in RUNPATH
2016-11-06 19:52 ` Hartmut Goebel
@ 2016-11-06 20:34 ` Danny Milosavljevic
2016-11-07 3:21 ` Chris Marusich
0 siblings, 1 reply; 6+ messages in thread
From: Danny Milosavljevic @ 2016-11-06 20:34 UTC (permalink / raw
To: Hartmut Goebel; +Cc: Guix-devel
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Phase `validate-runpath' fails: lib not in RUNPATH
2016-11-06 20:34 ` Danny Milosavljevic
@ 2016-11-07 3:21 ` Chris Marusich
2016-11-07 9:03 ` Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Chris Marusich @ 2016-11-07 3:21 UTC (permalink / raw
To: Danny Milosavljevic; +Cc: Guix-devel
[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]
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? Why would we need to add code here to do
that for this one package? I thought it would happen automatically.
--
Chris
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Phase `validate-runpath' fails: lib not in RUNPATH
2016-11-07 3:21 ` Chris Marusich
@ 2016-11-07 9:03 ` Ludovic Courtès
0 siblings, 0 replies; 6+ messages in thread
From: Ludovic Courtès @ 2016-11-07 9:03 UTC (permalink / raw
To: Chris Marusich; +Cc: Guix-devel
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 ‘ld’ wrapper (in gnu/packages/ld-wrapper.in) arranges
to add a -Wl,-rpath flag for each -l flag that it sees.
However, the ‘ld’ wrapper does not add such a flag if there’s no
corresponding -l flag, or if Thunderbird somehow managed to bypass the
wrapper altogether.
I’d suggest checking the link command line for the offending .so in
Thunderbird to see exactly what’s going on. It might just be that it
misses -lnspr4 or something like that.
HTH,
Ludo’.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-11-07 9:04 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-11-06 18:11 Phase `validate-runpath' fails: lib not in RUNPATH Hartmut Goebel
2016-11-06 19:28 ` Ricardo Wurmus
2016-11-06 19:52 ` Hartmut Goebel
2016-11-06 20:34 ` Danny Milosavljevic
2016-11-07 3:21 ` Chris Marusich
2016-11-07 9:03 ` Ludovic Courtès
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.