Closed fxcoudert closed 1 year ago
yeah, that does not look like something down to us
I don't have any spare h/w at the moment to use for 13beta.
Filed with Apple as FB11369327
I've been able to find a simple reproducer:
$ /usr/bin/ld .libs/libstdc++.lax/libc++98convenience.a/basic_file.o
ld: warning: could not create compact unwind for __ZNSt12__basic_fileIcE8sys_openEP7__sFILESt13_Ios_Openmode: registers 19 and 20 not saved contiguously in frame
ld: warning: could not create compact unwind for __ZNSt12__basic_fileIcE8sys_openEiSt13_Ios_Openmode: registers 19 and 20 not saved contiguously in frame
ld: warning: could not create compact unwind for __ZNSt12__basic_fileIcE6xsgetnEPcl: registers 21 and 22 not saved contiguously in frame
ld: warning: could not create compact unwind for __ZNSt12__basic_fileIcE8xsputn_2EPKclS2_l: registers 25 and 26 not saved contiguously in frame
ld: warning: could not create compact unwind for __ZNSt12__basic_fileIcE7seekoffExSt12_Ios_Seekdir: registers 19 and 20 not saved contiguously in frame
ld: warning: could not create compact unwind for __ZNSt12__basic_fileIcE9showmanycEv: registers 19 and 20 not saved contiguously in frame
0 0x102cc01a0 __assert_rtn + 140
1 0x102b47a8c mach_o::relocatable::Parser<arm64>::parse(mach_o::relocatable::ParserOptions const&) + 4536
2 0x102b19d38 mach_o::relocatable::Parser<arm64>::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const&) + 148
3 0x102b824ac ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool) + 1468
4 0x102b85360 ___ZN2ld4tool10InputFilesC2ER7Options_block_invoke + 56
5 0x1b170a5b0 _dispatch_client_callout2 + 20
6 0x1b171f21c _dispatch_apply_serial + 164
7 0x1b170a570 _dispatch_client_callout + 20
8 0x1b170f914 _dispatch_sync_function_invoke + 52
9 0x1b171e9e4 _dispatch_apply_with_attr_f + 1324
10 0x1b171eb48 dispatch_apply + 108
11 0x102b851f4 ld::tool::InputFiles::InputFiles(Options&) + 616
12 0x102b076c0 main + 552
A linker snapshot was created at:
/tmp/ld_snapshot-6
ld: Assertion failed: (_file->_atomsArrayCount == computedAtomCount && "more atoms allocated than expected"), function parse, file macho_relocatable_file.cpp, line 2061.
on the object file attached at https://www.dropbox.com/s/ngdjmpal0sh9zhd/basic_file.o?dl=0
we do invoke the linker with "no_compact_unwind", I assume? .. maybe that is not honoured for arm64 objects (perhaps that also explains some of the unwind fails we see in the c++ testsuite). It would be useful to be able to look at the sources for a more recent ld64 to see what it is expecting.
Yes we invoke the linker with no_compact_unwind
, and a lot of other flags. I just wanted to have a minimal reproducer of the crash.
$ /usr/bin/ld .libs/libstdc++.lax/libc++98convenience.a/basic_file.o -no_compact_unwind
0 0x1008001a0 __assert_rtn + 140
1 0x100687a8c mach_o::relocatable::Parser<arm64>::parse(mach_o::relocatable::ParserOptions const&) + 4536
2 0x100659d38 mach_o::relocatable::Parser<arm64>::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const&) + 148
3 0x1006c24ac ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool) + 1468
4 0x1006c5360 ___ZN2ld4tool10InputFilesC2ER7Options_block_invoke + 56
5 0x1b170a5b0 _dispatch_client_callout2 + 20
6 0x1b171f21c _dispatch_apply_serial + 164
7 0x1b170a570 _dispatch_client_callout + 20
8 0x1b170f914 _dispatch_sync_function_invoke + 52
9 0x1b171e9e4 _dispatch_apply_with_attr_f + 1324
10 0x1b171eb48 dispatch_apply + 108
11 0x1006c51f4 ld::tool::InputFiles::InputFiles(Options&) + 616
12 0x1006476c0 main + 552
A linker snapshot was created at:
/tmp/ld_snapshot-8
ld: Assertion failed: (_file->_atomsArrayCount == computedAtomCount && "more atoms allocated than expected"), function parse, file macho_relocatable_file.cpp, line 2061.
good, that indicates that the flag is honoured but the problem remains.
<aside> FWIW, I did spend some time trying to figure out what is blocking the FSF unwind frame stuff from working with cc1as + l64 compact unwind .. and it seems that there are some problems in both places .. hopefully, I will get a chance to revisit it at some point .. </aside>
The crash is observed with:
@(#)PROGRAM:ld PROJECT:ld64-819.6
BUILD 15:07:15 Aug 3 2022
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 14.0.0, (clang-1400.0.29.102) (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 14.0.0 (tapi-1400.0.11)
The same command line works fine with:
@(#)PROGRAM:ld PROJECT:ld64-764
BUILD 11:29:07 May 17 2022
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 13.1.6, (clang-1316.0.21.2.5) (static support for 28, runtime is 28)
TAPI support using: Apple TAPI version 13.1.6 (tapi-1316.0.7.3)
14.0b3 seems to have @(#)PROGRAM:ld PROJECT:ld64-819.1.2
I try to re-test with that on Intel Monterey (as noted before, AFAIR it was working).
BTW: the 13.0 SDK in 14.0b3 does not work with GCC ... has that been fixed ? (/me has not got around to d/l latest CLT yet).
Apparently, not an Arm64-specific issue ...
14.0b3, Monterey, Intel ld64 version as above:
0 0x10a28800a __assert_rtn + 139
1 0x10a0bb32d mach_o::relocatable::Parser<x86_64>::parse(mach_o::relocatable::ParserOptions const&) + 4989
2 0x10a0ac02f mach_o::relocatable::Parser<x86_64>::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const&) + 207
3 0x10a122a64 ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool) + 2036
4 0x10a126030 ___ZN2ld4tool10InputFilesC2ER7Options_block_invoke + 48
5 0x7ff815c4534a _dispatch_client_callout2 + 8
6 0x7ff815c568f5 _dispatch_apply_invoke + 213
7 0x7ff815c45317 _dispatch_client_callout + 8
8 0x7ff815c54c0c _dispatch_root_queue_drain + 673
9 0x7ff815c5525c _dispatch_worker_thread2 + 160
10 0x7ff815df8f8a _pthread_wqthread + 256
A linker snapshot was created at:
/tmp/isl_test_cpp-2022-08-25-171904.ld-snapshot
ld: Assertion failed: (_file->_atomsArrayCount == computedAtomCount && "more atoms allocated than expected"), function parse, file macho_relocatable_file.cpp, line 2061.
the 13.0 SDK in 14.0b3 does not work with GCC
Have they again included some nonstandard construct in the headers? Do you have an example/idea of where the issue is? I can report it, but we should do it soon, so it gets fixed.
I will d/l latest and try it .. the fail happens before the ld64 one so that's not a blocker.
DECLARE_CONSTRAINED_PTR_TYPES
) is now known as FB11474414, and a fix is also being tested.This same linker failure is happening on 12.6 (Monterey).
Xcode 13.4.1
Build version 13F100
M1 Pro
@(#)PROGRAM:ld PROJECT:ld64-764
BUILD 11:29:07 May 17 2022
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 13.1.6, (clang-1316.0.21.2.5) (static support for 28, runtime is 28)
TAPI support using: Apple TAPI version 13.1.6 (tapi-1316.0.7.3)
@lukaso which issue? SDK or linker crash?
The linker bug is present in the released Xcode 14:
@(#)PROGRAM:ld PROJECT:ld64-819.6
BUILD 14:58:44 Aug 5 2022
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 14.0.0, (clang-1400.0.29.102) (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 14.0.0 (tapi-1400.0.11)
@lukaso which issue? SDK or linker crash?
Linker bug. [Updated my comment above.]
I don't understand any much of it , but if someone can guide me how to get rid of this error , then that would be very helpful ! Looking forward for the replies ! I am a beginner in C++ , and i use sublime text 3.0 to code basic DSA Questions ! While i was solving some of the questions , the error came in and i am struggling till now !
Even I m facing the same issue it popped for me today
I don't understand any much of it , but if someone can guide me how to get rid of this error , then that would be very helpful !
Going back for now to the previous Command Line Tools for Xcode 13.4 (or full Xcode if you need that, but I didn't try it), which can be downloaded from Apple here (note: free Apple Developer account required), did it for me.
I don't understand any much of it , but if someone can guide me how to get rid of this error , then that would be very helpful !
Going back for now to the previous Command Line Tools for Xcode 13.4 (or full Xcode if you need that, but I didn't try it), which can be downloaded from Apple here (note: free Apple Developer account required), did it for me.
The same "fix" sorts out PR106961, at least on x86_64 - aarch64 to be tried later!
I don't understand any much of it , but if someone can guide me how to get rid of this error , then that would be very helpful !
Going back for now to the previous Command Line Tools for Xcode 13.4 (or full Xcode if you need that, but I didn't try it), which can be downloaded from Apple here (note: free Apple Developer account required), did it for me.
Hey i have installed the Command Line Tools for Xcode 13.4 from Apple. Till now i haven't got the error yet , but if it happens i will inform you here brother. Thanks for the help , really grateful to you !
Hit this myself today. Does anyone know if 14.1 Beta fixes this issue? I'm trying to work out the right request for my admins, i.e., "Downgrade XCode" vs "Upgrade XCode".
Or can I keep XCode 14 (I don't do any apple development, just have it for clang), and just install/downgrade the command line tools?
Does anyone know if 14.1 Beta fixes this issue?
I did try the Command Line Tools for Xcode 14.1 beta (dated Sep 14) before downgrading and ran into the same bug. Only the downgrade worked for me.
Testes with 14.1 and I still get the error.
@matteocorti @gerlero Dang, thanks. Can you just install 13.4 on top of XCode 14? Or do you need to go full downgrade?
@matteocorti @gerlero Dang, thanks. Can you just install 13.4 on top of XCode 14? Or do you need to go full downgrade?
If you didn’t want to downgrade both, you could probably do
xcode-select -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
(maybe only need /Library/Developer/CommandLineTools
?)
@matteocorti @gerlero Dang, thanks. Can you just install 13.4 on top of XCode 14? Or do you need to go full downgrade?
If you didn’t want to downgrade both, you could probably do
xcode-select -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
(maybe only need
/Library/Developer/CommandLineTools
?)
GCC only needs the command line tools.
You can also move the newer Xcode.app to somewhere outside Applications and then install the older one - the use Xcode-select -s to switch between those.
The CommandLineTools are self-contained within the /Library/Developer/CommandLineTools folder, so that you can also rename that to say CommandLineTools-14 and install the older one.
Unfortunately, you cannot use Xcode-select -s on the command line tools unless the folder is named 'CommandLineTools' (but of course you could also move the newer version into a sub-directory called 14.x).
I use the second approach a lot since I need to be able to switch versions to deal with bug reports.
Hi guys! I'm trying to install xcode command tools 13.4, but when I try to install it this message appear: The version of Mac Os is too new. Mac Os version : 13.0 beta(22A5353E) Do you know how to solve this?
Hi guys! I'm trying to install xcode command tools 13.4, but when I try to install it this message appear: The version of Mac Os is too new. Mac Os version : 13.0 beta(22A5353E) Do you know how to solve this?
Probably there is no easy way...
.. usually, it is possible to build for OS N+1 on OS N (but using the latest Xcode). So if you revert your system to macOS 12 - then you should be able to use Xcode 13.4 for that and Xcode 14.x to build code for macOS 13 ..
We should expect that a compiler built to run on macOS 12 would also run on macOS 13 - it would be a huge surprise if that compatibility broke.
It is sad that there aren't any solutions available other than downgrading the Xcode version.] lets wait then.
It is sad that there aren't any solutions available other than downgrading the Xcode version.] lets wait then.
What other solutions did you have in mind?
if there's a bug in the linker it is outside of our control (since we do not have the source code for any version > 12.0 at present).
I think some of these things are drifting outside of the parts I have some input to :)
The Command Line Tools 14.1 beta 3 released today fixed this for me (both for building gcc 12.2 release and this branch).
I don't understand any much of it , but if someone can guide me how to get rid of this error , then that would be very helpful !
Going back for now to the previous Command Line Tools for Xcode 13.4 (or full Xcode if you need that, but I didn't try it), which can be downloaded from Apple here (note: free Apple Developer account required), did it for me.
Hey i have installed the Command Line Tools for Xcode 13.4 from Apple. Till now i haven't got the error yet , but if it happens i will inform you here brother. Thanks for the help , really grateful to you !
@notMash3r Can you please tell me the steps you followed after downloading Command Line Tools for Xcode 13.4
@notMash3r Can you please tell me the steps you followed after downloading Command Line Tools for Xcode 13.4
@iam-ness I was able to get this to (briefly) work for me by following this page essentially:
https://hacknicity.medium.com/working-with-multiple-versions-of-xcode-e331c01aa6bc
The annoying thing is after I did that, I found my computer reverted back to Xcode 14. The reason seems to have been a pushed update to 14.0.1 at some point (this was on a work machine so it's managed by mighty scripts behind the scenes). Once it did that, Xcode no longer let me set the machine to use the 13.4 CLT, all I had was the the choice of 14.0 or 14.0.1 😞
So, my admins were nice enough to install the 14.1 beta for me. I figure that should trump any 14.0.x releases...I hope.
So, my admins were nice enough to install the 14.1 beta for me. I figure that should trump any 14.0.x releases...I hope.
It does for me (so far, anyway). I can turn "Automatically keep my Mac up to date" back on.
I don't understand any much of it , but if someone can guide me how to get rid of this error , then that would be very helpful ! Looking forward for the replies ! I am a beginner in C++ , and i use sublime text 3.0 to code basic DSA Questions ! While i was solving some of the questions , the error came in and i am struggling till now !
Firstly, you have 2 choices : 1)Either wait for the next update of Xcode, where the issue would be resolved or 2)Follow the below steps :
Please go to https://developer.apple.com/download/all/ Enter your Apple Credentials Now Scroll Down and Find the "Command Line Tools for Xcode 14.1 beta 3" Download the dmg file and install the package You can restart your Mac once, after the installation, for the changes to take effect You will see that the issue is fixed
Thanks, man @staffle you are a lifesaver!
I don't understand any much of it , but if someone can guide me how to get rid of this error , then that would be very helpful ! Looking forward for the replies ! I am a beginner in C++ , and i use sublime text 3.0 to code basic DSA Questions ! While i was solving some of the questions , the error came in and i am struggling till now !
were you able to resolve this issue? i'm having the same problem on vs code
Another workaround is not to build gcc from source. So if you are forcing building from source, I worked around it this way:
sudo sed -i -e 's/buildfromsource always/buildfromsource never/g' /opt/local/etc/macports/macports.conf
sudo port clean gcc12
sudo port install gcc12
sudo sed -i -e 's/buildfromsource never/buildfromsource always/g' /opt/local/etc/macports/macports.conf
I don't understand any much of it , but if someone can guide me how to get rid of this error , then that would be very helpful ! Looking forward for the replies ! I am a beginner in C++ , and i use sublime text 3.0 to code basic DSA Questions ! While i was solving some of the questions , the error came in and i am struggling till now !
were you able to resolve this issue? i'm having the same problem on vs code
Have you tried the solution i mentioned? Link Not the actual solution but works.
Please go to https://developer.apple.com/download/all/ Enter your Apple Credentials Now Scroll Down and Find the "Command Line Tools for Xcode 14.1 beta 3"
If like me you don't have or want any "Apple Credentials", you can still get the beta. Just do
sudo touch /Library/Developer/CommandLineTools/.beta
and it will appear in Software Update!
please help me, i am using vscode and having this error?(m2 air macbook air)
please help me, i am using vscode and having this error?(m2 air macbook air)
Please see the comments above https://github.com/iains/gcc-12-branch/issues/6#issuecomment-1266660607
I'm on Xcode 14.1, and have the issue with /usr/bin/ld
being broken. Arm.
I'm on Xcode 14.1, and have the issue with
/usr/bin/ld
being broken. Arm.
I have just built gcc-12.2-pre-r1 and current gcc-master (on aarch64-darwin21 [arm64 macOS 12]) using XC 14.1 command line tools, without any problems. As far as I can tell, the linker bug is fixed there [and in the 14.1RC, in fact], so you will need to analyse your problem and provide some more details.
I'm on Xcode 14.1, and have the issue with
/usr/bin/ld
being broken. Arm.
Just installed Xcode 14.1 command line tools and re-installed gcc-12 from homebrew.
This error is still present
0 0x108e64ffa __assert_rtn + 139 1 0x108c9828d mach_o::relocatable::Parser<x86_64>::parse(mach_o::relocatable::ParserOptions const&) + 4989 2 0x108c88f8f mach_o::relocatable::Parser<x86_64>::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const&) + 207 3 0x108cff9d4 ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool) + 2036 4 0x108d02fa0 ___ZN2ld4tool10InputFilesC2ER7Options_block_invoke + 48 5 0x7ff80ff3c34a _dispatch_client_callout2 + 8 6 0x7ff80ff4ec45 _dispatch_apply_invoke_and_wait + 213 7 0x7ff80ff4e161 _dispatch_apply_with_attr_f + 1178 8 0x7ff80ff4e327 dispatch_apply + 45 9 0x108d02e2d ld::tool::InputFiles::InputFiles(Options&) + 669 10 0x108c73d48 main + 840 A linker snapshot was created at: /tmp/z-2022-12-01-205325.ld-snapshot ld: Assertion failed: (_file->_atomsArrayCount == computedAtomCount && "more atoms allocated than expected"), function parse, file macho_relocatable_file.cpp, line 2061. collect2: error: ld returned 1 exit status
@WildUtah please file an issue at Homebrew with a full report (source compiled, exact command line, etc)
is there any insight here? (my builds are working).
While bootstrapping gcc-12.2-pre-r1:
I'll have to find some time and file a report with Apple 😢