Hi Ludovic, Ludovic Courtès <[email protected]> writes:
> Hi, > > Maxim Cournoyer <[email protected]> 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
