Bugzilla – Bug 51617
polkitd and polkit-agent-helper-1 get installed in libprivdir which is not multilib compatible
Last modified: 2012-07-02 09:20:41 UTC
32bit ELFs go to /usr/lib32, 64bit ELFs go to /usr/lib64
/usr/lib64 is a symlink in non-true-multilib systems, like Gentoo AMD64, to /usr/lib so everything will work
but it is NOT a symlink on MIPS 64EL systems with 3 different ABIs, hence we see the following:
** (process:7239): WARNING **: Cannot spawn helper: Failed to execute child process "/usr/lib/polkit-1/polkit-agent-helper-1" (No such file or directory)
The hardcoded path is in:
helper_argv = PACKAGE_PREFIX "/lib/polkit-1/polkit-agent-helper-1";
"libprivdir" in src/polkitagent/Makefile.am
Any reason why these 3 binaries don't respect the multilib dir, but other files installed by polkit do? Like all the libraries it installs...
This is also not configurable by any --libexecdir switch which is very inconvinient, so far I'm using quite ugly sed-job in the polkit's packaging to overcome this...
(In reply to comment #0)
> Any reason why these 3 binaries don't respect the multilib dir, but other files
*2 binaries (typing error...)
/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or even /bin. It shares
absolutely zero things with the arch-specific $libdir ,or lib64/.
/usr/lib/<pkgname>/ is the canonical "application private directory". It has
the multi-lib or arch-specific rules as /bin.
It just happens to be the same directory as $libdir for 32bit installations
in the classic non-multi-arch layout, which might go away over time, but that
is absolutely no reason to symlink it away.
Having /lib pointing to /lib64 is plain wrong, and should not explicitly
be supported by upstream build systems. If it happens to be that libexecdir
works for that, then it's fine, but it is surely not treated as a bug if it
The directories are part of the de-facto ABI between the CoreOS components.
They are not public like bin/ or /usr/share/, but part of the contract
between the involved parties working on the basic system components. And
these directories are not meant to be changed for proper interoperability.
It's the same as /lib/udev/, which is surely not /lib64/udev/. Misguided
things like that should just be fixed, to remove the needless differences
between the Linux distributions.
Thanks for explanation Kay, you expressed it much better than I could have. Closing NOTABUG as there's no bug here.
I sort of expected this answer. Thanks for clarifying.
I filed http://bugs.gentoo.org/424423 to clean up Portage's multilib check that currently bails out on the 64bit ELF in /usr/lib/