Installing the sys-libs/pam package with the split-usr flag disabled produces broken symlinks inside of the /lib(64) directory: $ ls -la /lib64/libpam* lrwxrwxrwx 1 root root 12 Jul 21 09:33 /lib64/libpamc.so -> libpamc.so.0 lrwxrwxrwx 1 root root 16 Jul 21 09:33 /lib64/libpam_misc.so -> libpam_misc.so.0 lrwxrwxrwx 1 root root 11 Jul 21 09:33 /lib64/libpam.so -> libpam.so.0 the /usr/lib(64) directory, in contrast, has all symlinks properly set-up: $ ls -la /usr/lib64/libpam* lrwxrwxrwx 1 root root 17 Jul 21 09:33 /usr/lib64/libpamc.so -> libpamc.so.0.82.1 lrwxrwxrwx 1 root root 17 Jul 21 09:33 /usr/lib64/libpamc.so.0 -> libpamc.so.0.82.1 -rwxr-xr-x 1 root root 14464 Jul 21 09:33 /usr/lib64/libpamc.so.0.82.1 lrwxrwxrwx 1 root root 21 Jul 21 09:33 /usr/lib64/libpam_misc.so -> libpam_misc.so.0.82.1 lrwxrwxrwx 1 root root 21 Jul 21 09:33 /usr/lib64/libpam_misc.so.0 -> libpam_misc.so.0.82.1 -rwxr-xr-x 1 root root 14456 Jul 21 09:33 /usr/lib64/libpam_misc.so.0.82.1 lrwxrwxrwx 1 root root 16 Jul 21 09:33 /usr/lib64/libpam.so -> libpam.so.0.84.2 lrwxrwxrwx 1 root root 16 Jul 21 09:33 /usr/lib64/libpam.so.0 -> libpam.so.0.84.2 -rwxr-xr-x 1 root root 55832 Jul 21 09:33 /usr/lib64/libpam.so.0.84.2
Apologies, that report is misleading. Under further investigation I realized that libraries come from sys-libs/e2fsprogs-libs, so the problem is that split-usr flag should be synchronized between these two packages.
Sorry above message is meant for a different bug report.
I also noticed this when migrating to merged /usr layout.
Created attachment 583812 [details] ebuild patch
Patch from comment #4 does not look like an optimal solution. Most of code in multilib_src_install() is unnecessary. Build system already installs libpam.so, libpam_misc.so, libpamc.so symlinks. gen_usr_ldscript() already internally calls multilib_is_native_abi() and does nothing for non-native ABIs. I suggest: --- pam-1.3.1-r1.ebuild +++ pam-1.3.1-r1.ebuild @@ -80,23 +80,9 @@ multilib_src_install() { emake DESTDIR="${D}" install \ sepermitlockdir="${EPREFIX}/run/sepermit" - local prefix - if multilib_is_native_abi; then - prefix= - gen_usr_ldscript -a pam pamc pam_misc - else - prefix=/usr - fi - - # create extra symlinks just in case something depends on them... - local lib - for lib in pam pamc pam_misc; do - if ! [[ -f "${ED}"${prefix}/$(get_libdir)/lib${lib}$(get_libname) ]]; then - dosym lib${lib}$(get_libname 0) ${prefix}/$(get_libdir)/lib${lib}$(get_libname) - fi - done + gen_usr_ldscript -a pam pam_misc pamc } multilib_src_install_all() { find "${ED}" -type f -name '*.la' -delete || die
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #5) Yes, bet the whole point of this code (In reply to Arfrever Frehtes Taifersar Arahesis from comment #5) > Patch from comment #4 does not look like an optimal solution. > > Most of code in multilib_src_install() is unnecessary. > > Build system already installs libpam.so, libpam_misc.so, libpamc.so symlinks. *.so symlinks are removed by gen_usr_ldscript(), that's why I didn't remove that code. See this comment: > # create extra symlinks just in case something depends on them... Though I'm not sure they are really needed.
(In reply to Alexander Tsoy from comment #6) > (In reply to Arfrever Frehtes Taifersar Arahesis from comment #5) > Yes, bet the whole point of this code (In reply to Arfrever Frehtes > Taifersar Arahesis from comment #5) > > Patch from comment #4 does not look like an optimal solution. > > > > Most of code in multilib_src_install() is unnecessary. > > > > Build system already installs libpam.so, libpam_misc.so, libpamc.so symlinks. > *.so symlinks are removed by gen_usr_ldscript(), that's why I didn't remove > that code. See this comment: > > # create extra symlinks just in case something depends on them... > Though I'm not sure they are really needed. For non-native ABIs gen_usr_ldscript() does not delete anything, does not create anything, does not move anything. For native ABI gen_usr_ldscript(): - Moves actual library (e.g. "libpam.so.0.84.2") and soname-versioned symlink (e.g. "libpam.so.0") from /usr/lib(64) to /lib(64) - Replaces unversioned symlink (e.g. "libpam.so") in /usr/lib(64) with linker script Either symlink to actual library, or linker script (with correct "GROUP ( /path/to/library )" line) is sufficient for linker. When -lpam is passed to linker, then linker searches for "libpam.so" and "libpam.a", but not e.g. "libpam.so.0". (Passing -l:libpam.so.0 would result in searching explicitlly for "libpam.so.0".) Linker reads soname of library (e.g. "libpam.so.0") and hardcodes it in NEEDED section of created file. At run time, ld.so searches for file which matches entry in NEEDED section (e.g. "libpam.so.0", not "libpam.so"). "libpam.so" is not used at run time.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #7) > For non-native ABIs gen_usr_ldscript() does not delete anything, does not > create anything, does not move anything. > > For native ABI gen_usr_ldscript(): > - Moves actual library (e.g. "libpam.so.0.84.2") and soname-versioned > symlink (e.g. "libpam.so.0") from /usr/lib(64) to /lib(64) > - Replaces unversioned symlink (e.g. "libpam.so") in /usr/lib(64) with > linker script Maybe I should have also mentioned that gen_usr_ldscript() does not do anything also when USE="-split-usr" is used: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cc8063d4318a6594ac8ae94e99c2a6fe484198bd So a 'use split-usr' check in ebuild is not needed before calling gen_usr_ldscript().
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #7) > (In reply to Alexander Tsoy from comment #6) > > (In reply to Arfrever Frehtes Taifersar Arahesis from comment #5) > > Yes, bet the whole point of this code (In reply to Arfrever Frehtes > > Taifersar Arahesis from comment #5) > > > Patch from comment #4 does not look like an optimal solution. > > > > > > Most of code in multilib_src_install() is unnecessary. > > > > > > Build system already installs libpam.so, libpam_misc.so, libpamc.so symlinks. > > *.so symlinks are removed by gen_usr_ldscript(), that's why I didn't remove > > that code. See this comment: > > > # create extra symlinks just in case something depends on them... > > Though I'm not sure they are really needed. > > For non-native ABIs gen_usr_ldscript() does not delete anything, does not > create anything, does not move anything. > > For native ABI gen_usr_ldscript(): > - Moves actual library (e.g. "libpam.so.0.84.2") and soname-versioned > symlink (e.g. "libpam.so.0") from /usr/lib(64) to /lib(64) > - Replaces unversioned symlink (e.g. "libpam.so") in /usr/lib(64) with > linker script > > Either symlink to actual library, or linker script (with correct "GROUP ( > /path/to/library )" line) is sufficient for linker. > > When -lpam is passed to linker, then linker searches for "libpam.so" and > "libpam.a", but not e.g. "libpam.so.0". > (Passing -l:libpam.so.0 would result in searching explicitlly for > "libpam.so.0".) > Linker reads soname of library (e.g. "libpam.so.0") and hardcodes it in > NEEDED section of created file. > > At run time, ld.so searches for file which matches entry in NEEDED section > (e.g. "libpam.so.0", not "libpam.so"). > "libpam.so" is not used at run time. Well, symlinks these days are not needed just because SONAME is a major one field during linking, which is '.0' in anyway.
(In reply to Mikle Kolyada from comment #9) Your comment is unclear about whether you have understood what I had said, so I will add more explanation. soname != filename soname and filename of a library are independent of each other, and neither of them needs to be a subset or a superset of the other one. soname is searched for only at run time (by ld.so). A library called "libA.so" in filesystem can have soname = "libB.so". This just means that a "libB.so" needs to exist somewhere at run time. (Potentially it can be a symlink to "libA.so".) $ cd /tmp $ gcc -shared -fPIC -Wl,--soname,libB.so -o libA.so -x c - </dev/null $ scanelf --soname libA.so TYPE SONAME FILE ET_DYN libB.so libA.so $ gcc -o test -x c - <<< "int main(){}" -Wl,-rpath,. -L. -lA $ scanelf --needed test TYPE NEEDED FILE ET_DYN libB.so,libc.so.6 test $ ./test ./test: error while loading shared libraries: libB.so: cannot open shared object file: No such file or directory $ ln -s libA.so libB.so $ ./test $
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #10) > (In reply to Mikle Kolyada from comment #9) > > Your comment is unclear about whether you have understood what I had said, > so I will add more explanation. > > soname != filename > soname and filename of a library are independent of each other, and neither > of them needs to be a subset or a superset of the other one. > soname is searched for only at run time (by ld.so). > > A library called "libA.so" in filesystem can have soname = "libB.so". > This just means that a "libB.so" needs to exist somewhere at run time. > (Potentially it can be a symlink to "libA.so".) > > $ cd /tmp > $ gcc -shared -fPIC -Wl,--soname,libB.so -o libA.so -x c - </dev/null > $ scanelf --soname libA.so > TYPE SONAME FILE > ET_DYN libB.so libA.so > $ gcc -o test -x c - <<< "int main(){}" -Wl,-rpath,. -L. -lA > $ scanelf --needed test > TYPE NEEDED FILE > ET_DYN libB.so,libc.so.6 test > $ ./test > ./test: error while loading shared libraries: libB.so: cannot open shared > object file: No such file or directory > $ ln -s libA.so libB.so > $ ./test > $ I know what soname is, there is no need to waste everybody's time with this offtopic (in the scope of this bug).
Created attachment 586804 [details, diff] Patch
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9b8c9d3b0871206e6f6f984213c493efadea297a commit 9b8c9d3b0871206e6f6f984213c493efadea297a Author: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org> AuthorDate: 2019-08-15 00:06:27 +0000 Commit: Mikle Kolyada <zlogene@gentoo.org> CommitDate: 2019-08-16 11:25:08 +0000 sys-libs/pam: Drop unnecessary code for creation of symlinks. Closes: https://bugs.gentoo.org/690322 Signed-off-by: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org> Signed-off-by: Mikle Kolyada <zlogene@gentoo.org> sys-libs/pam/pam-1.3.1-r1.ebuild | 16 +--------------- 1 file changed, 1 insertion(+), 15 deletions(-)
But next time please use either 'Bug:' or 'Closes:', not 'Fixes:' (I've corrected this on the way).
