Phase `validate-runpath' fails: lib not in RUNPATH

Phase `validate-runpath' fails: lib not in RUNPATH

[Hartmut Goebel]

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 |

Re: Phase `validate-runpath' fails: lib not in RUNPATH

[Ricardo Wurmus]

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

Re: Phase `validate-runpath' fails: lib not in RUNPATH

[Hartmut Goebel]

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 |

Re: Phase `validate-runpath' fails: lib not in RUNPATH

[Danny Milosavljevic]

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.

Re: Phase `validate-runpath' fails: lib not in RUNPATH

[Chris Marusich]

[-- 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 --]

Re: Phase `validate-runpath' fails: lib not in RUNPATH

[Ludovic Courtès]

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