Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 815874 - 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
Summary: sys-libs/glibc-2.33-r1 with crypt enabled in current latest stage3 and confli...
Status: RESOLVED DUPLICATE of bug 811462
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux bug wranglers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-03 02:10 UTC by fkhp
Modified: 2021-10-03 19:28 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log.txt,36.35 KB, text/plain)
2021-10-03 03:40 UTC, fkhp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description fkhp 2021-10-03 02:10:58 UTC
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.

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

the current stage3 need to be upgraded to enforce -crypt and put libxcrypt in teh system set.

Reproducible: Always
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-10-03 02:14:50 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.
Comment 2 fkhp 2021-10-03 02:38:48 UTC
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"
Comment 3 fkhp 2021-10-03 03:40:22 UTC
Created attachment 742575 [details]
build.log

build.log of libffi to show the failed scanelf lead to failed preserve_old_lib,
Comment 4 fkhp 2021-10-03 03:44:31 UTC
> 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.
Comment 5 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-10-03 04:15:34 UTC
(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 ***
Comment 6 fkhp 2021-10-03 16:19:44 UTC
(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.
Comment 7 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-10-03 19:28:39 UTC
(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.