On macOS 13, Gentoo Prefix fails to compile sys-devel/binutils-apple-8.2.1-r101: due to missing Blocks support in GCC, creating the following error: > /Users/ec2-user/gentoo/MacOSX.sdk/usr/include/objc/runtime.h:373:29: > error: expected ')' before '^' token > 373 | void (^ _Nonnull block)(Class _Nonnull aClass, BOOL * _Nonnull stop) > | ^ > | ) The likely solution has already been identified and the patch is currently being tested. Originally reported in Bug 898610, it's now created as a dedicated issue for clarity.
Interestingly, it broke (gcc-12.2?) in another way on darwin17 In file included from /Scratch-Local/Gentoo/bootstrap64-20230426/var/tmp/portage /sys-devel/binutils-apple-8.2.1-r101/work/darwin-xtools-gentoo-8.2.1-r101/ld64/s rc/ld/parsers/macho_relocatable_file.cpp:37: /Scratch-Local/Gentoo/bootstrap64-20230426/var/tmp/portage/sys-devel/binutils-ap ple-8.2.1-r101/work/darwin-xtools-gentoo-8.2.1-r101/ld64/src/ld/parsers/libunwin d/DwarfInstructions.hpp:36:10: fatal error: algorithm: No such file or directory 36 | #include <algorithm> | ^~~~~~~~~~~ compilation terminated. The same code surely worked before.
<algorithm> is new in C++17, so might be related to that (either before it was using -std=c++14 or similar, or the code conditionally uses stuff if building w/ >= c++17 but for some reason the header is missing).
(In reply to Sam James from comment #2) > <algorithm> is new in C++17, so might be related to that (either before it > was using -std=c++14 or similar, or the code conditionally uses stuff if > building w/ >= c++17 but for some reason the header is missing). No, algorithm is not new in C++17. std::algorithm has been an integral part of the C++ programming language since decades ago. Not only that, it cannot even find std::vector! > /Users/ec2-user/gentoo/var/tmp/portage/sys-devel/binutils-apple-8.2.1-r101/work > /darwin-xtools-gentoo-8.2.1-r101/ld64/src/other/PruneTrie.cpp:24:10: fatal > error: vector: No such file or directory > 24 | #include <vector> > | ^~~~~~~~ >compilation terminated. The problem appears to be the side-effect of the flag "-stdlib=libc++". This flag is only valid for clang, not GCC. Normally the error should simply be "unknown option", but for some reason, in this instance, it prevents GCC from recognizing the C++ standard library header altogether. Manually removing the flag allows the build to continue. Note: this is a preliminary result and the fix is still untested, I'm still working on troubleshooting and testing.
It seems that GCC 12.2 no longer rejects "-stdlib=libc++" as an invalid flag, instead, it prevents GCC from locating the C++ standard library. bash-3.2$ cat main.cpp #include <vector> int main(void) { } bash-3.2$ g++ main.cpp -o main -stdlib=libc++ main.cpp:1:10: fatal error: vector: No such file or directory 1 | #include <vector> | ^~~~~~~~ compilation terminated. The side-effect of this change is significant - most ./configure scripts attempts to check whether "-stdlib=libc++" is a valid option using a dummy program. It's suppose to fail and the build system knows it's GCC. But now it escapes detection until the dummy program contains "include" statement. This is strange. I suspect it's a regression GCC 12.2 (or GCC on x64) as an attempt to improve compatibility, but the unintended consequence is instead breaking compatibility.
feels like, we should mask GCC 12.2 again until this gets fixed?
(In reply to Fabian Groffen from comment #5) > feels like, we should mask GCC 12.2 again until this gets fixed? I'm still testing it. I haven't yet verified whether GCC 12.1 is unaffected.
Let's open a new issue for the second GCC problem, it's clearly independent from the previous Blocks issue in binutils-apple.
I opened Bug 905152.
With GCC 12.2 masked, let's return to this binutils-apple bug for now. I plan to submit and test a patch today to fix it. After it's fixed, let's bump the snapshot version again for macOS so we can get bootstrapping working again as soon as possible.
(In reply to Tom Li from comment #3) > (In reply to Sam James from comment #2) > > <algorithm> is new in C++17, so might be related to that (either before it > > was using -std=c++14 or similar, or the code conditionally uses stuff if > > building w/ >= c++17 but for some reason the header is missing). > > No, algorithm is not new in C++17. std::algorithm has been an integral part > of the C++ programming language since decades ago. Not only that, it cannot > even find std::vector! > Sorry, you are right, oops. > > /Users/ec2-user/gentoo/var/tmp/portage/sys-devel/binutils-apple-8.2.1-r101/work > > /darwin-xtools-gentoo-8.2.1-r101/ld64/src/other/PruneTrie.cpp:24:10: fatal > > error: vector: No such file or directory > > 24 | #include <vector> > > | ^~~~~~~~ > >compilation terminated. > > The problem appears to be the side-effect of the flag "-stdlib=libc++". This > flag is only valid for clang, not GCC. Normally the error should simply be > "unknown option", but for some reason, in this instance, it prevents GCC > from recognizing the C++ standard library header altogether. Manually > removing the flag allows the build to continue. > It's valid for gcc if you configure it to be: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=662b9c55cf06d3df6682ef865fb2b685820317a9 > Note: this is a preliminary result and the fix is still untested, I'm still > working on troubleshooting and testing.
(In reply to Sam James from comment #10) > It's valid for gcc if you configure it to be: > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=662b9c55cf06d3df6682ef865fb2b685820317a9 First, please, when a separate bug report has been created, please continue the discussion in the new report instead of following the original thread. I thought you and I have already learned this lesson after yesterday's mishaps. But for completeness: It's not valid, it's questionable. The GCC Darwin fork forces this option regardless of whether it's configured or not, unlike mainline GCC. And without explicit configuration, the default search path for libc++ is totally invalid, making it unusable. This seemingly harmless change also has far-reaching unintended consequences of breaking the assumption of many ./configure scripts. I already published a detailed report in Bug 905152, and it shall NOT be repeated here.
Your comment comes across a bit lecturing, keep in mind that people might read their emails in order and reply accordingly.
I just opened a Pull Request at https://github.com/gentoo/gentoo/pull/30781 to fix this problem for macOS 13 (both Intel and ARM64), along with two other problems on ARM64.
I'm still waiting for Pull Request #2 "[cctools] fix ar(1) crash without argument" to be merged into grobian/darwin-xtools, so that a new release can be made for binutils-apple to fix Bug 905131.
with these changes I can compile, but still get: configure:3335: checking whether we are cross compiling configure:3343: arm64-apple-darwin22-gcc -o conftest -O2 -pipe - D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -Wl,- dead_strip_dylibs conftest.c >&5 ld: warning: URGENT: building for OSX, but linking in object file (/Users/Gentoo-13/var/tmp/portage/sys-devel/bc-1.07.1-r6/temp/ccsokQgL.o) built for iOS. Note: This will be an error in the future. configure:3347: $? = 0 configure:3354: ./conftest ./configure: line 3356: 73346 Killed: 9 ./conftest$ac_cv_exeext configure:3358: $? = 137 configure:3365: error: in `/Users/Gentoo-13/var/tmp/portage/sys-devel/bc- 1.07.1-r6/work/bc-1.07.1': The urgent warning we can fix in the code to make it iOS, but that doesn't solve the problem either IIRC.
(In reply to Fabian Groffen from comment #15) > The urgent warning we can fix in the code to make it iOS, but that doesn't > solve the problem either IIRC. I see. The original bug affects both x64 and ARM64 bootstrap. In binutils-apple-8.2.1-r102, at least x64 bootstrap is now fixed. Meanwhile on ARM64, binutils-apple remains masked, so let's keep it as-is. So this bug can probably be closed as RESOLVED FIXED. I'll retest it soon and close this bug myself.
Slightly off-topic here: I verified on two boxes running 13.3/13.4 that bootstrap now works on arm64-macos. arm uses native-cctools, indeed. Compiling binutils-apple now works, so we can close this particular bug. Ok, let's do that and revisit the issue later.
(In reply to Fabian Groffen from comment #17) > bootstrap now works on arm64-macos. arm uses native-cctools, indeed. Retested on x64-macos, I confirm it works.
