bug#73979: validate-runpath phases fails when binaries linked to package's own libraries

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> There's a common pattern in packages where the validate-runpath phases
>> fail, which is when a binary is linked to libraries provided by the same
>> package.  In this case, our ld-wrapper script appears to not bake the
>> required runpath, which then fails the validate-runpath phase.
>>
>> When this happens, the common workaround is adding link directives such
>> as (string-append "-Wl,-rpath=" #$output "/lib/subdir") to LDFLAGS (see
>> for example the 'dmraid' package definition).
>
> I believe this is the exception, not the rule, and I see that as a bug
> in the build system of those packages.  (As a counterexample, any
> package built with Automake/Libtool is fine.)

Interesting.  I had not considered that point of view (that the build
system/usage of it could be at cause) enough; I think you are right.

[...]

>> One idea could be to allow creating rpaths to %BUILD-DIRECTORY prefixed
>> libraries, and have these entries refined in a phase that would run
>> after the package is installed, before the validate-runpath phase runs.
>> It could be called e.g. 'sanitize-runpath' and proceed along those
>> lines:
>>
>> Scan for RUNPATH entries being prefixed by %BUILD-DIRECTORY; attempt to
>> have them rewritten to libraries (.so) found under the package's own
>> libdir library prefix (at any depth), including a potential "lib"
>> output.  In case it couldn't, it would error.
>>
>> Does that sound feasible?
>
> It might be feasible, but I think it’s the wrong approach.  The problem
> here is in the build system itself; Guix is “not at fault”, so to speak.
>
> Nevertheless, from a practical viewpoint, whether or not Guix is at
> fault is largely irrelevant.  So the question becomes: how widespread is
> this issue?  If it’s widespread, can it be solved at a (guix
> build-system …) level?  (For instance, I think ‘cmake-build-system’ and
> ‘meson-build-system’ do the right things in that regard.)

I think CMake nowadays doesn't relink but uses some ELF-patching code to
patch the installed binaries in place (which is faster than relinking);
that would mean our ld-wrapper doesn't get involved in these case and we
depend on RPATH being enabled in the CMake build system, which it
normally is unless the package set CMAKE_SKIP_RPATH to false.  I guess
Meson is also patching binaries for speed.

> If it’s a per-package issue, which seems to be the case given what you
> describe, then I would fix it locally in this package, for instance by
> passing ‘-Wl,-rpath=$ORIGIN/../lib’ or whatever is convenient.

There doesn't seem to be so many occurrences; grepping for
'-Wl,-rpath.*output' I find 73 problematic packages.  I've found one
place where this happens is for Cythonized shared objects; this produced
shared objects linked to a library of the build directory, and is not
concerned with installing so nothing rewrites the runpath entries to
their correct installed location.  One such example is openpmix; the
issue was dismissed as "we expect people to set LD_LIBRARY_PATH" [0].

[0]  https://github.com/openpmix/openpmix/issues/3457

Anyway, sorry for the wall of text.  Closing!

-- 
Thanks,
Maxim