Summary: | sys-devel/gcc-config deletes libunwind.so from sys-libs/libunwind when /lib and /usr/lib are merged | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dennis Schridde <dschridde+gentoobugs> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexander, base-system, floppym |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=693252 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 699900 | ||
Bug Blocks: | 690294 | ||
Attachments: |
build.log.xz
gcc-config-2.0-handle-usrmerge.patch gcc-config-2.0-handle-usrmerge.patch Patch for gcc-config.git Patch for gentoo.git (sys-libs/libunwind) Patch implementing short term solution |
Description
Dennis Schridde
2018-09-25 06:28:27 UTC
Created attachment 547854 [details]
build.log.xz
Another candidate to blame might be the default/linux/amd64/17.1 profile, which changed library paths. Just the same as for the other suspicions though: I cannot confirm that, either. > I somehow suspect this is related to me having USE=-split-usr
If your /{lib,lib64} are symlinks to /usr/{lib,lib64} and you don't have separate /usr partition, then this might be a gcc-config bug:
# If /usr isn't a sep mount, then don't bother with linking stuff.
if ln "${ROOT}/${LDPATH}/libgcc.a" "${ROOT}"/lib/.gcc.config.$$ 2>/dev/null ; then
rm -f "${ROOT}"/lib/.gcc.config.$$
if [[ -n $(find "${ROOT}"/lib*/lib{gcc_s,unwind}.so* 2>/dev/null) ]] ; then
# If we previously had stuff in /, make sure ldconfig gets re-run.
rm -f "${ROOT}"/lib*/lib{gcc_s,unwind}.so*
return 1
fi
return 0
fi
(In reply to Alexander Tsoy from comment #3) > > I somehow suspect this is related to me having USE=-split-usr > If your /{lib,lib64} are symlinks to /usr/{lib,lib64} and you don't have > separate /usr partition, then this might be a gcc-config bug: /usr is on the same partition as /, but in a different subvolume: /dev/bcache0 on / type btrfs (rw,nodev,noatime,compress=zstd,ssd,space_cache,subvolid=257,subvol=/@gentoo) /dev/bcache0 on /usr type btrfs (rw,nodev,noatime,compress=zstd,ssd,space_cache,subvolid=1659,subvol=/@gentoo-usr) (In reply to Dennis Schridde from comment #4) > /usr is on the same partition as /, but in a different subvolume: So.. is it possible to create hardlink on a different subvolume? Relevant line from the code snippet in my previous comment: > if ln "${ROOT}/${LDPATH}/libgcc.a" "${ROOT}"/lib/.gcc.config.$$ 2>/dev/null ... (In reply to Alexander Tsoy from comment #5) > So.. is it possible to create hardlink on a different subvolume? Nevermind. Looks like hard links across subvolumes are not allowed. Created attachment 556956 [details, diff] gcc-config-2.0-handle-usrmerge.patch (In reply to Alexander Tsoy from comment #3) > > I somehow suspect this is related to me having USE=-split-usr > If your /{lib,lib64} are symlinks to /usr/{lib,lib64} and you don't have > separate /usr partition, then this might be a gcc-config bug: > > # If /usr isn't a sep mount, then don't bother with linking stuff. > if ln "${ROOT}/${LDPATH}/libgcc.a" "${ROOT}"/lib/.gcc.config.$$ > 2>/dev/null ; then > rm -f "${ROOT}"/lib/.gcc.config.$$ > if [[ -n $(find "${ROOT}"/lib*/lib{gcc_s,unwind}.so* 2>/dev/null) ]] > ; then > # If we previously had stuff in /, make sure ldconfig gets > re-run. > rm -f "${ROOT}"/lib*/lib{gcc_s,unwind}.so* > return 1 > fi > return 0 > fi We are on the right track: # gcc-config -l [1] riscv64-unknown-elf-7.2.0 * [2] x86_64-pc-linux-gnu-8.2.0 * # ll /usr/lib64/libunwind.so* lrwxrwxrwx 1 root root 18 Dec 2 17:24 /usr/lib64/libunwind.so -> libunwind.so.8.0.1 lrwxrwxrwx 1 root root 18 Dec 2 17:24 /usr/lib64/libunwind.so.8 -> libunwind.so.8.0.1 -rwxr-xr-x 1 root root 59520 Dec 2 17:24 /usr/lib64/libunwind.so.8.0.1 # gcc-config -f 1 * Switching cross-compiler to riscv64-unknown-elf-7.2.0 ... >>> Regenerating /etc/ld.so.cache... [ ok ] # ll /usr/lib64/libunwind.so* lrwxrwxrwx 1 root root 18 Dec 2 17:24 /usr/lib64/libunwind.so -> libunwind.so.8.0.1 lrwxrwxrwx 1 root root 18 Dec 2 17:24 /usr/lib64/libunwind.so.8 -> libunwind.so.8.0.1 -rwxr-xr-x 1 root root 59520 Dec 2 17:24 /usr/lib64/libunwind.so.8.0.1 # gcc-config -f 2 * Switching native-compiler to x86_64-pc-linux-gnu-8.2.0 ... >>> Regenerating /etc/ld.so.cache... [ ok ] * If you intend to use the gcc from the new profile in an already * running shell, please remember to do: * . /etc/profile # ll /usr/lib64/libunwind.so* ls: cannot access '/usr/lib64/libunwind.so*': No such file or directory I enabled tracing in gcc-config (`set -x`) and found this in the logs: + handle_split_usr + local LDPATH ++ grep -h '^LDPATH=' /etc/env.d/gcc/x86_64-pc-linux-gnu-8.2.0 ++ tail -1 + eval 'LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0:/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/32"' ++ LDPATH=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0:/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/32 + LDPATH=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0 + ln ///usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/libgcc.a //lib/.gcc.config.20775 + rm -f //lib/.gcc.config.20775 ++ find '//lib*/libgcc_s.so*' '//lib*/libgcc_s*dylib' //lib64/libunwind.so //lib64/libunwind.so.8 //lib64/libunwind.so.8.0.1 //lib/libunwind.so //lib/libunwind.so.8 //lib/libunwind.so.8.0.1 '//lib*/libunwind*dylib' + [[ -n //lib64/libunwind.so //lib64/libunwind.so.8 //lib64/libunwind.so.8.0.1 //lib/libunwind.so //lib/libunwind.so.8 //lib/libunwind.so.8.0.1 ]] + rm -f '//lib*/libgcc_s.so*' '//lib*/libgcc_s*dylib' //lib64/libunwind.so //lib64/libunwind.so.8 //lib64/libunwind.so.8.0.1 //lib/libunwind.so //lib/libunwind.so.8 //lib/libunwind.so.8.0.1 '//lib*/libunwind*dylib' + return 1 (In reply to Alexander Tsoy from comment #6) > (In reply to Alexander Tsoy from comment #5) > > So.. is it possible to create hardlink on a different subvolume? > Nevermind. Looks like hard links across subvolumes are not allowed. While this may be correct, it does not apply here. In my case /usr/lib/ and /lib/ are on the same subvolume (even though /usr/lib and /lib are not!). Attached patch is my attempt to fix this and works for me. Created attachment 556958 [details, diff]
gcc-config-2.0-handle-usrmerge.patch
Improved commit message and comments
Please fix summary of the bug. This should also block bug #690294 Confirming. This bug had been a constant companion for the last 2(?) years. (In reply to Alexander Tsoy from comment #9) > Please fix summary of the bug. This should also block bug #690294 What is wrong with the summary? (In reply to Dennis Schridde from comment #11) > What is wrong with the summary? This is a bug in sys-devel/gcc-config, so it should be in summary. I tried to find this bug recently and that took me some time. :) Also baselayout and profile are unrelated to this bug imo. @toolchain, gcc-config tries to copy libunwind.so* from gcc's LDPATH. This was introduced in [1] (before sys-libs/libunwind was added to the tree). Is this still needed for some arches and/or gcc versions? Maybe the code that handles libunwind.so should be completely removed from gcc-config? [1] https://gitweb.gentoo.org/proj/gcc-config.git/commit/?id=b3ff223fe02bfb4e04c730564f3c3f33565e07b7 (In reply to Alexander Tsoy from comment #13) > @toolchain, gcc-config tries to copy libunwind.so* from gcc's LDPATH. This > was introduced in [1] (before sys-libs/libunwind was added to the tree). Is > this still needed for some arches and/or gcc versions? Maybe the code that > handles libunwind.so should be completely removed from gcc-config? > > [1] > https://gitweb.gentoo.org/proj/gcc-config.git/commit/ > ?id=b3ff223fe02bfb4e04c730564f3c3f33565e07b7 I think it's still needed for arches with complex exception unwinder like ia64. There libunwind gets linked into many binaries by default. AFAIU libgcc_s is in the same boat and it's more widespread. The patch from comment #8 looks generally good. [ ] should be [[ ]]. Both checks (for Prefix and the new proposed one) could be moved to the beginning of handle_split_usr() function. (In reply to Sergei Trofimovich from comment #14) > I think it's still needed for arches with complex exception unwinder like > ia64. There libunwind gets linked into many binaries by default. AFAIU > libgcc_s is in the same boat and it's more widespread. While the code for libgcc_s.so might need to remain in gcc-config, the simpler solution for libunwind.so is to change sys-libs/libunwind to install all shared libraries to /lib instead of /usr/lib. (In reply to Arfrever Frehtes Taifersar Arahesis from comment #15) > The patch from comment #8 looks generally good. Actually not. Comparing /lib and /usr/lib is a bad idea. Even when /lib and /usr/lib are the same directory, /usr/lib/gcc could be on a separate filesystem, in which case gcc-config should still create /lib/libgcc_s.so.*. Created attachment 588574 [details, diff]
Patch for gcc-config.git
Created attachment 588576 [details, diff]
Patch for gentoo.git (sys-libs/libunwind)
Comment on attachment 588576 [details, diff] Patch for gentoo.git (sys-libs/libunwind) Patch obsolete in favor of new patches for bug #693250 and bug #693252. stop handling of libunwind (at least on ia64) in gcc-config might be good enough solution but we have too many moving parts at the same time: 1. gcc-config should stop fiddlind with /lib/libunwind.so* 2. while sys-libs/libunwind moves into /lib 3. while gcc starts linking to /lib's libunwind Updating in wrong order will render system unusable for user. While the problem to solve here is somewhat straightforward: stop overriding /usr/lib/libunwind.so when /lib and /usr/lib are the same thing (or always). I think we should fix one thing at a time to be able to roll back safely if problems arise. Thus I suggest fixing gcc-config first and see if we can tweak the rest as a cleanup (if possible). To recap: what gcc-config does here is it preserves a copy of libgcc_s and it's dependencies somewhere in /lib for the case when /usr/lib is not available yet. It copies those to /lib assuming ldconfig finds it there. I suggest: change gcc-config's location for libgcc_s copy to be a standalone directory, say LDPATH=/lib/libgcc_s-backup and dump files there. That should allows us to release gcc-config separately and check if it works. (In reply to Sergei Trofimovich from comment #20) Currently gcc-config (only on IA64) creates /lib/libunwind.so.7 (which can be also /usr/lib/libunwind.so.7 when /lib and /usr/lib are merged), but does not create /lib/libunwind.so Notice .so.* instead of .so* in this line: https://gitweb.gentoo.org/proj/gcc-config.git/tree/gcc-config?id=9b907ef80bc421df23515afc4c306e4d96c67649#n320 >=sys-libs/libunwind-1.0.1 installs: /usr/lib/libunwind.so (which can be also /lib/libunwind.so) /usr/lib/libunwind.so.8 (which can be also /lib/libunwind.so.8) /usr/lib/libunwind.so.8.0.1 (or 8.0.0 in older version) (which can be also /lib/libunwind.so.8.0.1) gcc-config firstly deletes all libunwind.so* which matches libraries coming from both sys-devel/gcc and sys-libs/libunwind: https://gitweb.gentoo.org/proj/gcc-config.git/tree/gcc-config?id=9b907ef80bc421df23515afc4c306e4d96c67649#n303 Until final solution is hopefully accepted, the simpler workaround is to change gcc-config to delete only libunwind.so.7* WITHOUT libunwind.so and libunwind.so.8. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/gcc-config.git/commit/?id=17c4c852f979668387b1b965d48470cb730df5b6 commit 17c4c852f979668387b1b965d48470cb730df5b6 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-09-04 18:59:31 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-09-04 18:59:31 +0000 gcc-config: clarify why libunwind.so* is needed at all Bug: https://bugs.gentoo.org/667020 Bug: https://bugs.gentoo.org/693252 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> gcc-config | 5 +++++ 1 file changed, 5 insertions(+) https://gitweb.gentoo.org/proj/gcc-config.git/commit/?id=f4139631463fe56aebf3c04a44f8691ccd044c01 commit f4139631463fe56aebf3c04a44f8691ccd044c01 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-09-04 18:53:38 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-09-04 18:53:38 +0000 gcc-config: don't perform a cleanup for prefix systems Patch by [Arfrever]. No changes in actual handling of /lib*/ file on non-prefix systems yet. Bug: https://bugs.gentoo.org/667020 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> gcc-config | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) Created attachment 589056 [details, diff]
Patch implementing short term solution
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/gcc-config.git/commit/?id=ff954c6b20686d490d1382f90d2a4d64754bb18e commit ff954c6b20686d490d1382f90d2a4d64754bb18e Author: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org> AuthorDate: 2019-09-04 19:29:58 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-09-05 06:28:11 +0000 gcc-config: During initial clean-up, delete only libunwind.so.7*, but not other files matching libunwind.so*. libunwind.so belongs to sys-libs/libunwind. libunwind.so.7* is copied by gcc-config (only on ia64) from active version of sys-devel/gcc. libunwind.so.8* belong to sys-libs/libunwind since 1.0.1 version released on 2011-09-11. [slyfox@: sumplified 'return' statement] Bug: https://bugs.gentoo.org/667020 Signed-off-by: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org> gcc-config | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) (In reply to Sergei Trofimovich from comment #20) > stop handling of libunwind (at least on ia64) in gcc-config might be good > enough solution but we have too many moving parts at the same time: > 1. gcc-config should stop fiddlind with /lib/libunwind.so* > 2. while sys-libs/libunwind moves into /lib > 3. while gcc starts linking to /lib's libunwind > > Updating in wrong order will render system unusable for user. > > While the problem to solve here is somewhat straightforward: stop overriding > /usr/lib/libunwind.so when /lib and /usr/lib are the same thing (or always). > > I think we should fix one thing at a time to be able to roll back safely if > problems arise. > > Thus I suggest fixing gcc-config first and see if we can tweak the rest as a > cleanup (if possible). To recap: what gcc-config does here is it preserves a > copy of libgcc_s and it's dependencies somewhere in /lib for the case when > /usr/lib is not available yet. It copies those to /lib assuming ldconfig > finds it there. > > I suggest: > change gcc-config's location for libgcc_s copy to be a standalone directory, > say > LDPATH=/lib/libgcc_s-backup > and dump files there. That should allows us to release gcc-config separately > and check if it works. Implemented LDPATH backup as: https://gitweb.gentoo.org/proj/gcc-config.git/commit/?id=44570a44be60a8fc33bd05089047c1f2980b3047 Will add a bit of verbosity around copying backup libraries and will cut a gcc-config-2.1. For now gcc-config-9999 should be in a good shape to test the changes. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/gcc-config.git/commit/?id=04d7a13d933a0fb7266df332ddaa2a2d1141d7be commit 04d7a13d933a0fb7266df332ddaa2a2d1141d7be Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-09-07 22:44:34 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-09-07 22:44:34 +0000 Revert "gcc-config: store gcc backup into /lib/gcc-backup, not /lib" This reverts commit 44570a44be60a8fc33bd05089047c1f2980b3047. Unfortunately ld.so does has static set of fallback paths when it fails to lookup shared library from ld.so.cache: those are /lib64 and /usr/lib64 on amd64. Let's revert the change and jkeep relying on /lib64 for now. Bug: https://bugs.gentoo.org/667020 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> Makefile | 22 +++------------------- envd-gcc-backup | 3 --- gcc-backup/README | 41 ----------------------------------------- gcc-config | 18 +----------------- 4 files changed, 4 insertions(+), 80 deletions(-) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cc51dde0d07754dd5ce1155424d730274372739f commit cc51dde0d07754dd5ce1155424d730274372739f Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-09-08 09:13:26 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-09-08 09:15:09 +0000 sys-devel/gcc-config: bump up to 2.1 - Don't cleanup /lib/libunwind.so (bug #667020) - Drop GCC_PATH reconstruction (bug #174422) - Use findmnt for mountpoint check when available (bug #693588) - drop /etc/env.d/gcc/.NATIVE symlink - drop /etc/env.d/gcc/config migration code - drop empty /etc/env.d/05gcc-${CTARGET} files - add einfo logging around library backup Bug: https://bugs.gentoo.org/667020 Bug: https://bugs.gentoo.org/174422 Bug: https://bugs.gentoo.org/693588 Package-Manager: Portage-2.3.75, Repoman-2.3.17 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-devel/gcc-config/Manifest | 1 + sys-devel/gcc-config/gcc-config-2.1.ebuild | 54 +++++++++++++++++++++++++++++ sys-devel/gcc-config/gcc-config-9999.ebuild | 4 +-- 3 files changed, 57 insertions(+), 2 deletions(-) libunwind.so destruction should be sorted out. Longer-term work to move libunwind to /lib is in related tickets. |