Closed git-bruh closed 1 year ago
Logically this can be fixed by making ldd treat any Nvm, this won't work if the library exists in $RPATH
as $1/$RPATH
(basically treating the build dir as root and giving it higher priority than rootfs) but this will again cause issues if the $RPATH
belongs to a seperate package/$RPATH
AND /usr/lib
but not in the package dir
Simple fix https://libera.irclog.whitequark.org/kisslinux/2022-09-05#32887554;
Alternatively, we could just skip this mess altogether and not try to resolve dependencies if a non-relative RPATH (not $ORIGIN) is set for a library
Afaik firefox is the only program that uses rpath apart from llvm (which uses $ORIGIN)
Setting RPATH to
$ORIGIN
works mostly fine, but it breaks for one library that firefox installs inside a subdirectory,/usr/lib/firefox/gmp-clearkey/0.1/libclearkey.so
This library links to NSS, and say if we were to bundle nss/nspr again in the future, it will incur a dependency on system
nss
asldd
will resolve/usr/lib/libnss3.so
since$ORIGIN/libnss3.so
, i.e/usr/lib/firefox/gmp-clearkey/0.1/libnss3.so
doesn't existRPATH can't be set to
/usr/lib/firefox
either as, when system firefox has bundled nss and firefox is built with system nss, it will again get a dependency on system firefox as/usr/lib/firefox/libnss3.so
exists...We probably need to rework the dependency detector to completely alleviate such issues. In addition to these issues, the detector will also break in case of symlinks to absolute paths.
/usr/bin/firefox
is linked to/usr/lib/firefox/firefox-bin
. This isn't currently an issue since that binary only links to libc, however it would cause the same issues again if it were to link to a system / bundled libraryCC @illiliti