When bootstrapping Gentoo Prefix on macOS 13.2 (Ventura) on an Apple M1 system, it will fail at stage2 due to a sys-devel/gcc-12.2.0 build failure. make[3]: Entering directory '/Users/leo/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-12.2.0/work/build/libcc1' /Users/leo/Gentoo/tmp/bin/bash ./libtool --tag=CXX --mode=link g++ -m64 -std=gnu++11 -W -Wall -fvisibility=hidden -Wl,-undefined,dynamic_lookup -I/Users/leo/Gentoo/tmp/usr/include -pipe -O2 -module -export-symbols /Users/leo/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-12.2.0/work/gcc-12-branch-gcc-12.2-darwin-r0/libcc1/libcc1.sym -Wc,-nodefaultrpaths,-nodefaultexport -Wl,-rpath,@loader_path '-Wl,-search_paths_first' '-L/Users/leo/Gentoo/tmp/usr/lib' -o libcc1.la -rpath /Users/leo/Gentoo/tmp/usr/lib/ findcomp.lo libcc1.lo libcp1.lo compiler.lo names.lo callbacks.lo connection.lo marshall.lo -Wc,../libiberty/pic/libiberty.a libtool: link: sed -e 's,^,_,' < /Users/leo/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-12.2.0/work/gcc-12-branch-gcc-12.2-darwin-r0/libcc1/libcc1.sym > .libs/libcc1-symbols.expsym libtool: link: g++ -m64 -std=gnu++11 -o .libs/libcc1.0.so -bundle .libs/findcomp.o .libs/libcc1.o .libs/libcp1.o .libs/compiler.o .libs/names.o .libs/callbacks.o .libs/connection.o .libs/marshall.o -L/Users/leo/Gentoo/tmp/usr/lib -m64 -Wl,-undefined -Wl,dynamic_lookup -nodefaultrpaths -nodefaultexport -Wl,-rpath -Wl,@loader_path -Wl,-search_paths_first ../libiberty/pic/libiberty.a -Wl,-exported_symbols_list,.libs/libcc1-symbols.expsym clang: error: unknown argument: '-nodefaultrpaths' clang: error: unknown argument: '-nodefaultexport' make[3]: *** [Makefile:576: libcc1.la] Error 1 make[3]: Leaving directory '/Users/leo/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-12.2.0/work/build/libcc1' make[3]: *** Waiting for unfinished jobs.... Currently, both sys-devel/gcc-12.1.0 and sys-devel/gcc-12.2.0 have problems. However, sys-devel/gcc-12.1.0 can be fixed after applying two patches, as I've described in Bug #895332. Meanwhile, the solution of this sys-devel/gcc-12.2.0 bug is unclear. I suggest masking sys-devel/gcc-12.2.0 on macOS for now until someone finishes investigation of the issue. Meanwhile, we can fix sys-devel/gcc-12.1.0 according to Bug #895332. It would allow a successful bootstrap on macOS 13.2.
For patches, I just created a Pull Request on GitHub: https://github.com/gentoo/prefix/pull/17
I've determined the nature of the bug. Basically, currently Gentoo Prefix bootstrap uses a hack of linking GCC output using LLVM/clang during the early stages, as seen in the bootstrap script source code: *"Apple clang version "*|*"Apple LLVM version "*) # recent binutils-apple are hard to build (C++11 # features, and cmake build system) so avoid going # there, the system ld is good enough to bring us to # stage3, after which the @system set will take care of # the rest linker=sys-devel/native-cctools ;; This practice is not officially supported by GCC developers, nevertheless it worked in GCC 12.1.0 and earlier versions. Since GCC 12.2.0, in order to support the new embedded rpath feature on Darwin, two incompatible options, "-nodefaultrpaths" and "-nodefaultexport" were introduced in upstream commit 07d831a [1] and released in GCC 12.2.0. Thus, on Darwin, linking with anything other than GCC would fail. So the 100% fix would be linking GCC with GCC instead of keep relying on this hack. But since the use of these options is controlled by the configure flag --enable-darwin-at-rpath and the macro ENABLE_DARWIN_AT_RPATH, for the purpose of bootstrapping a Gentoo prefix, these options can be used to maintain the existing behavior of the hack. [1] https://github.com/iains/gcc-12-branch/commit/07d831a7cdc20efdc6fe504a9d291050eec0705a
For more information about the background of this rpath problem, see my discussion with GCC maintainer Iain Sandoe.
For more information about the background of this rpath problem, see my discussion with GCC maintainer Iain Sandoe at https://github.com/iains/gcc-12-branch/issues/18.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=5ceb16d0ba609a4d29d5eccf24b01b2942a16a98 commit 5ceb16d0ba609a4d29d5eccf24b01b2942a16a98 Author: Yifeng Li <tomli@tomli.me> AuthorDate: 2023-02-18 22:29:10 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-02-19 18:53:03 +0000 sys-devel/gcc-12.2.0: mask macOS, it's broken. When bootstrapping Gentoo Prefix on macOS 13.2 (Ventura) on an Apple M1 system, it will fail at stage2 due to a sys-devel/gcc-12.2.0 build failure. make[3]: Entering directory '/Users/leo/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-12.2.0/work/build/libcc1' /Users/leo/Gentoo/tmp/bin/bash ./libtool --tag=CXX --mode=link g++ -m64 -std=gnu++11 -W -Wall -fvisibility=hidden -Wl,-undefined,dynamic_lookup -I/Users/leo/Gentoo/tmp/usr/include -pipe -O2 -module -export-symbols /Users/leo/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-12.2.0/work/gcc-12-branch-gcc-12.2-darwin-r0/libcc1/libcc1.sym -Wc,-nodefaultrpaths,-nodefaultexport -Wl,-rpath,@loader_path '-Wl,-search_paths_first' '-L/Users/leo/Gentoo/tmp/usr/lib' -o libcc1.la -rpath /Users/leo/Gentoo/tmp/usr/lib/ findcomp.lo libcc1.lo libcp1.lo compiler.lo names.lo callbacks.lo connection.lo marshall.lo -Wc,../libiberty/pic/libiberty.a libtool: link: sed -e 's,^,_,' < /Users/leo/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-12.2.0/work/gcc-12-branch-gcc-12.2-darwin-r0/libcc1/libcc1.sym > .libs/libcc1-symbols.expsym libtool: link: g++ -m64 -std=gnu++11 -o .libs/libcc1.0.so -bundle .libs/findcomp.o .libs/libcc1.o .libs/libcp1.o .libs/compiler.o .libs/names.o .libs/callbacks.o .libs/connection.o .libs/marshall.o -L/Users/leo/Gentoo/tmp/usr/lib -m64 -Wl,-undefined -Wl,dynamic_lookup -nodefaultrpaths -nodefaultexport -Wl,-rpath -Wl,@loader_path -Wl,-search_paths_first ../libiberty/pic/libiberty.a -Wl,-exported_symbols_list,.libs/libcc1-symbols.expsym clang: error: unknown argument: '-nodefaultrpaths' clang: error: unknown argument: '-nodefaultexport' make[3]: *** [Makefile:576: libcc1.la] Error 1 make[3]: Leaving directory '/Users/leo/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-12.2.0/work/build/libcc1' make[3]: *** Waiting for unfinished jobs.... Currently, both sys-devel/gcc-12.1.0 and sys-devel/gcc-12.2.0 have problems. However, sys-devel/gcc-12.1.0 can be fixed after applying two patches, as I've described in Bug #895332 [1]. Meanwhile, the solution of this sys-devel/gcc-12.2.0 bug [2] is unclear. This commit masks sys-devel/gcc-12.2.0 on macOS for now until someone finishes investigation of the issue. Meanwhile, we can fix sys-devel/gcc-12.1.0 according to Bug #895332. It would allow a successful bootstrap on macOS 13.2. P.S: although the KEYWORDS says ~x64-macos, it's actually also controlling the behavior of ~arm64-macos as well. [1] https://bugs.gentoo.org/895332 [2] https://bugs.gentoo.org/895334 Bug: https://bugs.gentoo.org/895334 Signed-off-by: Yifeng Li <tomli@tomli.me> Signed-off-by: Sam James <sam@gentoo.org> sys-devel/gcc/gcc-12.2.0.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
The GCC 12.2 bug still needs a permanent fix. The easiest option is to simply pass "--disable-darwin-at-rpath" to GCC on macOS, this disables the new rpath feature during early bootstrap, allowing clang to link GCC objects. However, it means all GCC can only output binaries with hardcoded rpath. Although this is safe on Gentoo prefix, because moving the prefix is unsupported anyway. But this would be major restriction to end-users who wishes to use Gentoo's GCC to build projects outside Gentoo Prefix. I'm no ebuild guru. Does anyone know if there's a way to run code in an ebuild file at, during and ONLY during the process of Gentoo Prefix bootstrap (not GCC bootstrap). Please advice. Failing that, I think I'll just hack it to run if the GCC "bootstrap" keyword is unset. The three-stage GCC bootstrap is only normally skipped during the three-stage Gentoo bootstrap, and it's not a recommended setting for end users, so the risk of not supporting dynamic rpath is small.
(In reply to Tom Li from comment #6) > I'm no ebuild guru. Does anyone know if there's a way to run code in an > ebuild file at, during and ONLY during the process of Gentoo Prefix > bootstrap (not GCC bootstrap). Please advice. > You can conditionally pass EXTRA_ECONF="--disable-darwin-at-rpath" in the bootstrap-prefix.sh script.
I've just committed a fix to my private tree. I'll send a Pull Request after it's fulled tested.
Patch has been tested and it's working. I just opened a Pull Request at https://github.com/gentoo/prefix/pull/26
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=072ae8f5092b262a2c0007cdaed180895f665471 commit 072ae8f5092b262a2c0007cdaed180895f665471 Author: Yifeng Li <tomli@tomli.me> AuthorDate: 2023-04-24 05:56:14 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-04-24 20:11:57 +0000 sys-devel/gcc: unmask macOS for gcc-12.2.0 This commit reintroduces the keywords for macOS on both x64 and ARM64, which were previously masked. In commit 4528ff80dbcde18a90c4dfe64e8a3bd42fbfbf41, the bootstrap script has been patched to allow the use of sys-devel/gcc-12.2.0 on macOS. The previous mask is no longer necessary. Bug: https://bugs.gentoo.org/895334 Signed-off-by: Yifeng Li <tomli@tomli.me> Closes: https://github.com/gentoo/prefix/pull/26 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/gcc/gcc-12.2.0.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=1684174109750be2a0d96eba93d45ddea6f3c39e commit 1684174109750be2a0d96eba93d45ddea6f3c39e Author: Yifeng Li <tomli@tomli.me> AuthorDate: 2023-04-24 05:50:09 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-04-24 20:11:53 +0000 bootstrap-prefix.sh: use --disable-darwin-at-rpath in stage2 During Gentoo prefix bootstrap stage2, GCC is built with "--disable-bootstrap". For Darwin, it means that rather than letting GCC to eventually build itself using multiple passes, we're forcing it to build with the host LLVM/clang toolchain in a single pass. It's not officially supported, but practically it worked. However, since >=gcc-12.2.0, in order to support the new embedded rpath feature on Darwin, two incompatible options, "-nodefaultrpaths" and "-nodefaultexport" are introduced. This causes linking failures, since these options are only recognized by GCC and are unknown to LLVM/clang (hypothetically, using an older GCC possibly causes the same problem as well). Thus, embedded rpath should be disabled during prefix bootstrap stage2 via --disable-darwin-at-rpath in EXTRA_ECONF. Bug: https://bugs.gentoo.org/895334 Signed-off-by: Yifeng Li <tomli@tomli.me> Signed-off-by: Sam James <sam@gentoo.org> scripts/bootstrap-prefix.sh | 26 +++++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-)
Closing this one as it's fixed, unless I misunderstood (we can use the 'Closes:' tag for that in future commits, fwiw)
(In reply to Sam James from comment #11) > Closing this one as it's fixed, unless I misunderstood (we can use the > 'Closes:' tag for that in future commits, fwiw) The fix involves a bootstrap script change and an ebuild change, logically they're independent so it's better to make two commits. However, the problem is that in order to fix this issue, these two commits depend on each other and must be applied together. According to GLEP 66: > * Use atomic commits — one commit per logical change. > * Split commits at logical unit (package, eclass, profile…) > boundaries. > * Avoid creating commits that are 'broken' — e.g. are incomplete, > have uninstallable packages. > It is technically impossible to always respect all of the three > rules, so developers have to balance between them at their own discretion. My final decision was to use two commits, as a result, neither commit can be said to be "fix" of the issue on its own, so I used only "Bug:", not "Closes:".
(In reply to Tom Li from comment #12) The real purpose of the "Closes" tag is to trigger automatic closure of the bug report. Since both commits were submitted as a series in a PR, setting Closes on the last commit in the series would be appropriate.
