| Summary: | sys-libs/glibc-2.33-r1 with crypt enabled in current latest stage3 and conflict with -crypt forced for sys-libs/glibc in current portage | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | fkhp <fkhp101> |
| Component: | Current packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | build.log | ||
|
Description
fkhp
2021-10-03 02:10:58 UTC
(In reply to fkhp from comment #0) > with -crypt forced for sys-libs/glibc-2.33-r7, and with crypt enabled for > sys-libs/glibc-2.33-r1 in the current stage3. > For stable users, the profiles currently force glibc[crypt] and libxcrypt[-system]. For ~arch users, the profiles force the opposite. > emerge --ask --verbose --update --deep --newuse @world > > will fail after finished emerging glibc-2.33-r7, when emerge some package > with build time dependency on crypt lib, with error message: > fail loading libcrypt.so.1 > Getting this error should not be possible with FEATURES="preserved-libs" and indeed I don't see how it could happen even without it, given we call preserve_old_lib in glibc's ebuild. > the current stage3 need to be upgraded to enforce -crypt and put libxcrypt > in teh system set. > That's not quite right: - see bug 699422 for the details on the migration; - https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation has more information on the process and how to resolve conflicts too. I don't understand what problem is actually happening here (or how), but we're going to need some more concrete instructions on how to reproduce this and emerge output too. the preserve-libs FEATURE is set by default, so the error happened repeatedly is really strange. localhost ~ # emerge --info|grep preserve-libs FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles keepwork merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned qa-unresolved-soname-deps sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersync" Created attachment 742575 [details]
build.log
build.log of libffi to show the failed scanelf lead to failed preserve_old_lib,
> Getting this error should not be possible with FEATURES="preserved-libs" and > indeed I don't see how it could happen even without it, given we call > preserve_old_lib in glibc's ebuild. in termux proot, there's the "Bad system call" of scanelf issue (https://github.com/termux/proot/issues/187 ) using the workaround provided, the package could be merged in, but the old libs not be preserved as expected. (In reply to fkhp from comment #3) > Created attachment 742575 [details] > build.log > > build.log of libffi to show the failed scanelf lead to failed > preserve_old_lib, Now it makes far more sense! Let that be a lesson to share more in the first place ;) (In reply to fkhp from comment #4) > > Getting this error should not be possible with FEATURES="preserved-libs" and > > indeed I don't see how it could happen even without it, given we call > > preserve_old_lib in glibc's ebuild. > > in termux proot, there's the "Bad system call" of scanelf issue > (https://github.com/termux/proot/issues/187 ) > > using the workaround provided, the package could be merged in, but the old > libs not be preserved as expected. Yep, this is bug 811462. Try upgrading Portage first, although that won't fix whatever the root cause is with proot. We'd need strace output from scanelf to find the syscall which fails to go further here. *** This bug has been marked as a duplicate of bug 811462 *** (In reply to Sam James from comment #5) > (In reply to fkhp from comment #3) > > Created attachment 742575 [details] > > build.log > > > > build.log of libffi to show the failed scanelf lead to failed > > preserve_old_lib, > > Now it makes far more sense! Let that be a lesson to share more in the first > place ;) > > (In reply to fkhp from comment #4) > > > Getting this error should not be possible with FEATURES="preserved-libs" and > > > indeed I don't see how it could happen even without it, given we call > > > preserve_old_lib in glibc's ebuild. > > > > in termux proot, there's the "Bad system call" of scanelf issue > > (https://github.com/termux/proot/issues/187 ) > > > > using the workaround provided, the package could be merged in, but the old > > libs not be preserved as expected. > > Yep, this is bug 811462. Try upgrading Portage first, although that won't > fix whatever the root cause is with proot. > > We'd need strace output from scanelf to find the syscall which fails to go > further here. > > *** This bug has been marked as a duplicate of bug 811462 *** further debugging revealed that there's a typo in the file preserve_lib.eclass which was the root cause. the patch has been uploaded in bug 811462 report page. (In reply to fkhp from comment #6) > (In reply to Sam James from comment #5) > > (In reply to fkhp from comment #3) > > > Created attachment 742575 [details] > > > build.log > > > > > > build.log of libffi to show the failed scanelf lead to failed > > > preserve_old_lib, > > > > Now it makes far more sense! Let that be a lesson to share more in the first > > place ;) > > > > (In reply to fkhp from comment #4) > > > > Getting this error should not be possible with FEATURES="preserved-libs" and > > > > indeed I don't see how it could happen even without it, given we call > > > > preserve_old_lib in glibc's ebuild. > > > > > > in termux proot, there's the "Bad system call" of scanelf issue > > > (https://github.com/termux/proot/issues/187 ) > > > > > > using the workaround provided, the package could be merged in, but the old > > > libs not be preserved as expected. > > > > Yep, this is bug 811462. Try upgrading Portage first, although that won't > > fix whatever the root cause is with proot. > > > > We'd need strace output from scanelf to find the syscall which fails to go > > further here. > > > > *** This bug has been marked as a duplicate of bug 811462 *** > > > further debugging revealed that there's a typo in the file > preserve_lib.eclass which was the root cause. the patch has been uploaded in > bug 811462 report page. As explained at https://bugs.gentoo.org/811462#c23, that's not the case. |
