Summary: | sys-devel/gcc-7.2.0[multilib,obj-gc]: missing abi DEPEND on dev-libs/boehm-gc: configure: error: system bdw-gc required but not found | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Craig Andrews <candrews> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | andrius, arsen, candrews, corbinbird, daniel.santos, daniel, dark, ecyoung, elliot, evanjsx, gentoo, hydrapolic, luke-jr+gentoobugs, mae.lippert, mario.fetka, Martin.Jansa, mgorny, mlspamcb, orodruinlair, sam, sandino, tECHIDNA, thexor, toralf |
Priority: | Normal | Keywords: | PullRequest |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://github.com/gentoo/gentoo/pull/33216 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | gcc-build-logs.tar.bz2 |
Description
Craig Andrews
2017-05-08 02:54:09 UTC
Actually, I had boehm-gc-7.6.0 installed. (In reply to Michał Górny from comment #1) > Actually, I had boehm-gc-7.6.0 installed. That's surprising because above dependency is exactly what is missing. boehm-gc got debundled from gcc-7.1.0 and it now expects an external system copy. Installing boehm-gc prior to gcc installation fixes the configure error in the last stage. Maybe it's another multilib-strict failure? i.e. try it without the lib->lib64 symlink. commit 6f040a46b71eb17a7d7168c73825020b34fa691a Author: Matthias Maier <tamiko@gentoo.org> Date: Tue May 9 11:54:59 2017 -0500 toolchain.eclass: add DEPEND to dev-libs/boehm-gc, bug #617788 sys-devel/gcc-7.1.0 requires external dev-libs/boehm-gc, the internal copy got removed [1]. [1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=242985 commit a0dc3491f9924262a600533744150277899fb521 Author: David Seifert <soap@gentoo.org> Date: Wed May 10 22:41:03 2017 +0200 dev-libs/boehm-gc: Make multilib compatible Bug: https://bugs.gentoo.org/show_bug.cgi?id=617788 Package-Manager: Portage-2.3.5, Repoman-2.3.2 commit 05eb2b2a092fbc693def470d7fc448aa784bc7e5 Author: David Seifert <soap@gentoo.org> Date: Wed May 10 22:24:45 2017 +0200 dev-libs/libatomic_ops: Make multilib compatible Bug: https://bugs.gentoo.org/show_bug.cgi?id=617788 Package-Manager: Portage-2.3.5, Repoman-2.3.2 Reminder: toolchain.eclass somehow needs to DEPEND on dev-libs/boehm-gc[${MULTILIB_USEDEP}] if USE=obj-gc and multilib are enabled. The short-term hack would be to check if via 'has_version' calls, which is ugly, and the long-term hack would be putting it in a proper multilib? obj-gc? () clause in DEPEND. Given the implicit nature of how toolchain works, the latter could require a significant reengineering of the toolchain eclass. ...or just replacing the implicit with explicit. For the meantime, I think it would be reasonable to enable abi_x86_* by default in appropriate profiles for those packages. It might be worthwhile to finally clean up toolchain.eclass (with EAPI 5, or 6 support only) for gcc-7 and introduce proper multilib support. The multiarch / boehm-gc / gcc objc-gc issue is starting to cause issues for users since gcc 7.2 has been unmasked. See https://bugs.gentoo.org/638666 *** Bug 638666 has been marked as a duplicate of this bug. *** *** Bug 646416 has been marked as a duplicate of this bug. *** *** Bug 646052 has been marked as a duplicate of this bug. *** *** Bug 652890 has been marked as a duplicate of this bug. *** Confirmed this can be fixed by setting ABI_X86 to include both 32 and 64 for boehm-gc. So changing the dependency to include [abi_x86_32,abi_x86_64] (or appropriate for the given target) would probably be the solution. *** Bug 659048 has been marked as a duplicate of this bug. *** *** Bug 663286 has been marked as a duplicate of this bug. *** *** Bug 668758 has been marked as a duplicate of this bug. *** same issue on gcc-8.2.2[multilib,obj-gc] will provide info on demand if needed. Same for 'stable' sys-devel/gcc-8.3.0-r1. And for unstable sys-devel/gcc-9.2.0. I ran into this problem while moving away from an indiscriminate USE=abi_x86_32 in make.conf to more refined package.use settings. Here are some things I discovered: (1) Rebuilding dev-libs/boehm-gc-8.0.4 after subtracting abi_x86_32 nevertheless results in the creation of 32 bit libraries /lib/libgc.so.1.4.3 and /lib/libgc.so.1. However, a /lib/libgc.so symlink is NOT created. Also, entries in preserved_libs_registry were created for the (re)installed 32-bit libraries despite the fact that library versions were not changed. (2) Manually creating the /lib/libgc.so symlink allowed all GCC packages > 7 to recompile during an emerge @preserved-rebuild but that did NOT clear preserved_libs_registry. However, reinstalling dev-libs/boehm-gc-8.0.4[abi_x86_32] did end up clearing preserved_libs_registry without the need for another emerge @preserved-rebuild. (3) Not related to this bug but possibly of interest to package maintainers: according to https://www.hboehm.info/gc/, "starting with 8.0, libatomic_ops is only required if the compiler does not understand C atomics". Perhaps the unconditonal dependency on dev-libs/libatomic_ops in dev-libs/boehm-gc should be changed to a conditional dependency? I am guessing that this bug is not affecting too many users. *** Bug 725860 has been marked as a duplicate of this bug. *** *** Bug 789645 has been marked as a duplicate of this bug. *** *** Bug 789801 has been marked as a duplicate of this bug. *** *** Bug 798999 has been marked as a duplicate of this bug. *** *** Bug 801583 has been marked as a duplicate of this bug. *** Another user reproduced this today on IRC. should be add a objc-gc? ( dev-libs/boehm-gc[abi_x86_64] ) etc The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1a96b82a76b8d7fb824d4a7b47f6b70c1808936c commit 1a96b82a76b8d7fb824d4a7b47f6b70c1808936c Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2023-10-06 15:49:32 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-11-26 23:36:10 +0000 profiles/arch: Force multilib flags on sys-devel/gcc deps Force enabling respective abi_* flags on sys-devel/gcc dependencies in profiles where multiple MULTILIB_ABIS are used by default. This prevents sys-devel/gcc build from failing late in the build with cryptic error messages when USE=multilib (that is forced on) is used along with USE=objc. Bug: https://bugs.gentoo.org/617788 Signed-off-by: Michał Górny <mgorny@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/33216 Signed-off-by: Sam James <sam@gentoo.org> profiles/arch/amd64/no-multilib/package.use.force | 7 ++++++- profiles/arch/amd64/package.use.force | 6 ++++++ profiles/arch/amd64/x32/package.use.force | 6 ++++++ profiles/arch/mips/mips64/multilib/package.use.force | 8 ++++++++ profiles/arch/mips/mipsel/mips64el/multilib/package.use.force | 8 ++++++++ 5 files changed, 34 insertions(+), 1 deletion(-) objc is not a popular gcc build option, why not just handle this useflag requirement inside ebuild itself instead of forcing all profile users to comply, even those that don't use gcc[objc]? (In reply to Gino McCarty from comment #28) > objc is not a popular gcc build option, > > why not just handle this useflag requirement inside ebuild itself instead of > forcing all profile users to comply, even those that don't use gcc[objc]? Because it's impossible. (In reply to Gino McCarty from comment #28) > objc is not a popular gcc build option, > > why not just handle this useflag requirement inside ebuild itself instead of > forcing all profile users to comply, even those that don't use gcc[objc]? See the discussion above - there's no way to correctly specify it per platform. You're free to unforce it locally if you want, it's only for multilib profiles, and the two packages are very quick to build (and only depend on one of the others). |