| Summary: | sys-libs/glibc-2.33-r2 with FEATURES="-preserved-libs": missing libcrypt before merging sys-libs/libxcrypt-4.4.23-r1, Perl unable to run during build | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Duncan <1i5t5.duncan> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | marek.bartosiewicz, sam |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://github.com/gentoo/gentoo/pull/21680 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 699422 | ||
| Attachments: |
libxcrypt build log
perl -V output |
||
|
Description
Duncan
2021-07-15 00:37:32 UTC
If you could get us a log of the error, that would help (even if it's just a picture), but I suspect -preserved-libs is indeed relevant. Having the emerge log would be useful too (/var/log/emerge.log) in order to fully understand the merge order. Wondering if we need to use preserve-libs.eclass in glibc and libxcrypt (for going in the other direction, just in case) for now. FWIW, the issues you cite with preserved-libs shouldn't really exist anymore. But still, it's not strictly required to have it on, and it's not required by the package manager specification either. Created attachment 723925 [details]
libxcrypt build log
An emergency-system-restore-partition that's a backup/copy of the main system partition at the time it was created is great. I have full functionality, including manpage and web access, even access to youtube to play some music while I restore, just as I did at the time it was created. =:^)
Failed econf. Build log excerpt (as emerge --info says, perl-5.34.0::gentoo is installed):
checking for perl... /usr/sbin/perl
checking whether /usr/sbin/perl is version 5.14.0 or later... no
configure: error: Perl version 5.14.0 or later is required
(In reply to Duncan from comment #2) > Created attachment 723925 [details] > libxcrypt build log > > An emergency-system-restore-partition that's a backup/copy of the main > system partition at the time it was created is great. I have full > functionality, including manpage and web access, even access to youtube to > play some music while I restore, just as I did at the time it was created. > =:^) > > Failed econf. Build log excerpt (as emerge --info says, perl-5.34.0::gentoo > is installed): > > checking for perl... /usr/sbin/perl > checking whether /usr/sbin/perl is version 5.14.0 or later... no > configure: error: Perl version 5.14.0 or later is required Cheers for the quick reply! Throw me /tmp/portage/sys-libs/libxcrypt-4.4.23-r1/work/libxcrypt-4.4.23-xcrypt_compat-abi_x86_64.amd64/config.log? I assume 'perl -V' completely dies too, but show me it anyway? (In reply to Sam James from comment #1) > Having the emerge log would be useful too (/var/log/emerge.log) in order to > fully understand the merge order. Looking at emerge.log now. Pretty simple as I had updated yesterday so there wasn't much to update today. There were 14 packages to emerge but it only finished two and failed on the third (libxcrypt). Everything after that was skipped. 1) dev-libs/libxml2-2.9.12-r4 merged fine. 2) sys-libs/glibc-2.33-r2 merged fine. 3) sys-libs/libxcrypt-4.4.23-r1 failed. 4) Everything beyond that skipped. Here's that emerge, starting at line 411 of my (logrotated so it stays reasonable) emerge.log 411 1626305813: Started emerge on: Jul 14, 2021 16:36:52 412 1626305813: *** emerge --newuse --oneshot --update --ask --autounmask-unrestricted-atoms --autounmask-write=n --backtrack=20 --color=y --deep --dynamic-deps=n --implicit-system-deps=n --jobs=7 --keep-going --load-average=8.0 --with-bdeps=y --quiet-build=n --quiet-fail=y --regex-search-auto=y --selective --verbose @world 413 1626305823: *** terminating. 414 1626306084: >>> emerge (1 of 14) dev-libs/libxml2-2.9.12-r4 to / 415 1626306084: === (1 of 14) Cleaning (dev-libs/libxml2-2.9.12-r4::/p/gentoo/dev-libs/libxml2/libxml2-2.9.12-r4.ebuild) 416 1626306084: === (1 of 14) Compiling/Packaging (dev-libs/libxml2-2.9.12-r4::/p/gentoo/dev-libs/libxml2/libxml2-2.9.12-r4.ebuild) 417 1626306170: === (1 of 14) Merging (dev-libs/libxml2-2.9.12-r4::/p/gentoo/dev-libs/libxml2/libxml2-2.9.12-r4.ebuild) 418 1626306174: >>> AUTOCLEAN: dev-libs/libxml2:2 419 1626306174: === Unmerging... (dev-libs/libxml2-2.9.12-r3) 420 1626306175: >>> unmerge success: dev-libs/libxml2-2.9.12-r3 421 1626306177: === (1 of 14) Post-Build Cleaning (dev-libs/libxml2-2.9.12-r4::/p/gentoo/dev-libs/libxml2/libxml2-2.9.12-r4.ebuild) 422 1626306177: ::: completed emerge (1 of 14) dev-libs/libxml2-2.9.12-r4 to / 423 1626306177: >>> emerge (2 of 14) sys-libs/glibc-2.33-r2 to / 424 1626306177: === (2 of 14) Cleaning (sys-libs/glibc-2.33-r2::/p/gentoo/sys-libs/glibc/glibc-2.33-r2.ebuild) 425 1626306177: === (2 of 14) Compiling/Packaging (sys-libs/glibc-2.33-r2::/p/gentoo/sys-libs/glibc/glibc-2.33-r2.ebuild) 426 1626306617: === (2 of 14) Merging (sys-libs/glibc-2.33-r2::/p/gentoo/sys-libs/glibc/glibc-2.33-r2.ebuild) 427 1626306621: >>> AUTOCLEAN: sys-libs/glibc:2.2 428 1626306621: === Unmerging... (sys-libs/glibc-2.33-r1) 429 1626306623: >>> unmerge success: sys-libs/glibc-2.33-r1 430 1626306628: === (2 of 14) Post-Build Cleaning (sys-libs/glibc-2.33-r2::/p/gentoo/sys-libs/glibc/glibc-2.33-r2.ebuild) 431 1626306628: ::: completed emerge (2 of 14) sys-libs/glibc-2.33-r2 to / 432 1626306628: >>> emerge (3 of 14) sys-libs/libxcrypt-4.4.23-r1 to / 433 1626306628: === (3 of 14) Cleaning (sys-libs/libxcrypt-4.4.23-r1::/p/gentoo/sys-libs/libxcrypt/libxcrypt-4.4.23-r1.ebuild) 434 1626306628: === (3 of 14) Compiling/Packaging (sys-libs/libxcrypt-4.4.23-r1::/p/gentoo/sys-libs/libxcrypt/libxcrypt-4.4.23-r1.ebuild) 435 1626306646: *** Finished. Cleaning up... 436 1626306646: *** exiting unsuccessfully with status '1'. 437 1626306646: *** terminating. 438 (In reply to Duncan from comment #4) > (In reply to Sam James from comment #1) > > Having the emerge log would be useful too (/var/log/emerge.log) in order to > > fully understand the merge order. > > Looking at emerge.log now. Pretty simple as I had updated yesterday so > there wasn't much to update today. There were 14 packages to emerge but it > only finished two and failed on the third (libxcrypt). Everything after > that was skipped. > Thanks for the information! > 1) dev-libs/libxml2-2.9.12-r4 merged fine. > > 2) sys-libs/glibc-2.33-r2 merged fine. > > 3) sys-libs/libxcrypt-4.4.23-r1 failed. > Right, so because Perl is a BDEPEND of libxcrypt (unfortunately), we may need to call preserve_lib* in glibc to keep a copy of libcrypt around until libxcrypt replaces it. Created attachment 723931 [details] perl -V output (In reply to Sam James from comment #3) > Cheers for the quick reply! Throw me > /tmp/portage/sys-libs/libxcrypt-4.4.23-r1/work/libxcrypt-4.4.23- > xcrypt_compat-abi_x86_64.amd64/config.log? That's on tmpfs and I've rebooted to the backup, so unless it's stored somewhere permanent it's gone. > I assume 'perl -V' completely dies too, but show me it anyway? Note that I'm still on the backup, which I made June 9. However, looks like it's the same perl (my perl-5.34.0 binpkg is dated May 21) so I expect it's valid for the failed system, too. I should also mention another system oddity of mine, in case it turns out to matter: I have a reverse usrmerge, that is /usr -> . so everything that would be in /usr is in / itself. I have had a few symlink-overwriting-what-it-points-at bugs over the years, including one in glibc, but long ago INSTALL_MASKED the appropriate glibc files. Could the glibc/libxcrypt switchup have perturbed things and have overwritten another lib with its symlink? Contents of /etc/portage/env/pkg/env/installmask/glibc (which is pointed at by the appropriate package.env install.mask file to activate for glibc): # 2017.1112 glibc: libm-2.*.so due to /usr -> . symlink, # symlink overwrites the lib it points to! INSTALL_MASK="$INSTALL_MASK /usr/lib64/libm-2.*.so" [Originally missed the -r1 in the title/summary, updated.] Back on the normal working system again after manually copying the four libcrypt files from the backup. That confirms them going missing as the problem, tho I've not tried finishing my updates just yet. If I'm correct I should be able to --buildpkgonly libxcrypt to get the binpkg, then set collision-ignore or turn off collision-protect to merge the binpkg (tho I'm not sure, I may have to do that for the build too, to avoid portage resetting the environment to that used for the build during the binpkg install). After I get it merged I expect to be back in business and able to finish an @world update. (In reply to Duncan from comment #8) > If I'm correct I should be able to --buildpkgonly libxcrypt to get the > binpkg, then set collision-ignore or turn off collision-protect to merge the > binpkg (tho I'm not sure, I may have to do that for the build too, to avoid > portage resetting the environment to that used for the build during the > binpkg install). Just turned off collision-protect. Worked without turning it off the build, only the binpkg merge. =:^) Then from /lib64 (which with my reverse usrmerge is /usr/lib64 as well) did: for file in libcrypt*; do equery b $file; done ... to get the list of unowned/stale libcrypt files (libcrypt-2.33.so and libscrypt.a) to clean up. The rest of the @world update is going now with virtual/libcrypt-2 updated and perl already successfully rebuilt/remerged as well, so I seem to be back in business. =:^) So the bug is actually that glibc needs to preserve the libcrypt lib until libxcrypt is built, not a bug with libxcrypt per se. Updating title to reflect the glibc aspect, but keeping libxcrypt in the title too so it shows up regardless of which of the two packages is searched. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=31faab1325ce5042620ef12ad8eac9e7d0b1e9fc commit 31faab1325ce5042620ef12ad8eac9e7d0b1e9fc Author: Sam James <sam@gentoo.org> AuthorDate: 2021-07-16 22:10:43 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2021-07-17 17:11:13 +0000 sys-libs/libxcrypt: block sys-libs/glibc[crypt(+)] Bug: https://bugs.gentoo.org/802207 Signed-off-by: Sam James <sam@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/21680 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> sys-libs/libxcrypt/libxcrypt-4.4.23-r2.ebuild | 211 ++++++++++++++++++++++++++ 1 file changed, 211 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d6535cc0b605b03af4e35cff1bf8ba9f0691dfaf commit d6535cc0b605b03af4e35cff1bf8ba9f0691dfaf Author: Sam James <sam@gentoo.org> AuthorDate: 2021-07-16 22:09:32 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2021-07-17 17:11:04 +0000 sys-libs/glibc: add preserve-libs for libcrypt Bug: https://bugs.gentoo.org/802207 Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> sys-libs/glibc/glibc-2.33-r3.ebuild | 1534 +++++++++++++++++++++++++++++++++++ sys-libs/glibc/glibc-9999.ebuild | 16 +- 2 files changed, 1549 insertions(+), 1 deletion(-) I think this is probably as good as it gets. A collision will occur now, but at least the system isn't in a broken state. FEATURES="-protect-owned -collision-protect" will work when emerging libxcrypt. I suppose further doc updates are the only thing left. (In reply to Sam James from comment #12) > I think this is probably as good as it gets. A collision will occur now, but > at least the system isn't in a broken state. > > FEATURES="-protect-owned -collision-protect" will work when emerging > libxcrypt. I suppose further doc updates are the only thing left. Ack. If it could helps I have faced the same problem with FEATURES=" sandbox sfperms strict parallel-fetch -preserve-libs buildpkg " : - first I got file collision while building libxcrypt as glibc provide /lib64/libcrypt.so.1 so I do: emerge -v sys-libs/glibc (-crypt / 2.33-r7) - then I run: emerge -uDvN world and libxcrypt build failed on checking perl version > 5.14 so I run perl -V : it fails as it's linked to /lib64/libcrypt.so.1 which doesn't exist as it wasn't preserved. rebuilding perl fix the problem (revdep-rebuild would have fix it) - finaly with emerge -uDvvN world, the build of libxcrypt was ok and dependences are beeing rebuild. Perl may need to be rebuild to be linked againstlibxcrypt's /lib64/libcrypt.so.1. (In reply to Aurelien Minet from comment #14) > If it could helps I have faced the same problem with FEATURES=" sandbox > sfperms strict parallel-fetch -preserve-libs buildpkg " : You should not have -preserve-libs as it's rather dangerous but glibc should give you a message to run revdep-rebuild and rm the file manually if using -preserve-libs. > - first I got file collision while building libxcrypt as glibc provide > /lib64/libcrypt.so.1 so I do: emerge -v sys-libs/glibc (-crypt / 2.33-r7) Nit: you should do emerge -v --oneshot sys-libs/glibc. > - then I run: emerge -uDvN world and libxcrypt build failed on checking perl > version > 5.14 so I run perl -V : it fails as it's linked to > /lib64/libcrypt.so.1 which doesn't exist as it wasn't preserved. rebuilding > perl fix the problem (revdep-rebuild would have fix it) It should've been perserved by preserve_old_lib (even with FEATURES="-preserve-libs") though... > - finaly with emerge -uDvvN world, the build of libxcrypt was ok and > dependences are beeing rebuild. Perl may need to be rebuild to be linked > againstlibxcrypt's /lib64/libcrypt.so.1. OK, that's something. I think I'm hitting a side effect of this.
On embedded systems that I build all packages for on another machine, I often mask out headers, and static libraries with INSTALL_MASK.
Now glibc is failing because it cannot copy the non-present crypt.h when I go to install the binary.
* ERROR: sys-libs/glibc-2.33-r7::gentoo failed (preinst phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 127: Called pkg_preinst
* environment, line 2762: Called die
* The specific snippet of code:
* cp "${EROOT}"/usr/include/crypt.h "${T}"/crypt.h || die;
Wondering what is my best way forward? Two passes, one with headers and one without? Hand edit the ebuild to remove the ||die on the targets?
(In reply to David Flogeras from comment #16) > I think I'm hitting a side effect of this. > > On embedded systems that I build all packages for on another machine, I > often mask out headers, and static libraries with INSTALL_MASK. > > Now glibc is failing because it cannot copy the non-present crypt.h when I > go to install the binary. > > * ERROR: sys-libs/glibc-2.33-r7::gentoo failed (preinst phase): > * (no error message) > * > * Call stack: > * ebuild.sh, line 127: Called pkg_preinst > * environment, line 2762: Called die > * The specific snippet of code: > * cp "${EROOT}"/usr/include/crypt.h "${T}"/crypt.h || die; > > > Wondering what is my best way forward? Two passes, one with headers and one > without? Hand edit the ebuild to remove the ||die on the targets? I'll edit it to check if it exists (although please do file a new bug if you can in future, this one is getting very long ;)). The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3062f2ce92ef51f40385300dc9d3a3ec176bb9c6 commit 3062f2ce92ef51f40385300dc9d3a3ec176bb9c6 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-03 00:53:29 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-03 00:54:12 +0000 sys-libs/glibc: only copy crypt.h if it exists Some folks may have rather strict INSTALL_MASKs and such and don't need headers, so if they don't have it already, go with it. Bug: https://bugs.gentoo.org/802207 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/glibc/glibc-2.33-r7.ebuild | 15 +++++++++++++-- sys-libs/glibc/glibc-2.34.ebuild | 16 ++++++++++++++-- sys-libs/glibc/glibc-9999.ebuild | 15 +++++++++++++-- 3 files changed, 40 insertions(+), 6 deletions(-) |
