-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/link: issues with Apple's new linker in Xcode 15 beta #61229
Comments
I also have an ld assertion failure (reported to Apple as FB12550006):
|
@ismail Thanks for the report. The CL stack mentioned above (https://golang.org/cl/505415 and dependencies) also avoids the assertion failure. |
Change https://go.dev/cl/503935 mentions this issue: |
Change https://go.dev/cl/503538 mentions this issue: |
Change https://go.dev/cl/502616 mentions this issue: |
Change https://go.dev/cl/502617 mentions this issue: |
Change https://go.dev/cl/503539 mentions this issue: |
Change https://go.dev/cl/505415 mentions this issue: |
Change https://go.dev/cl/508696 mentions this issue: |
Change https://go.dev/cl/508697 mentions this issue: |
Another failure mode: (AMD64 Mac only, not ARM64) as of Xcode 15 beta 4 (
And the CLs above are not enough to fix it. I'm looking into it. (PIE binaries are fine. Also fine on ARM64 as it is always PIE.) |
I am on # golang.org/x/tools/cmd/goimports
ld: warning: '/private/var/folders/jc/lq1rvy214tq4643flbh887xr0000gn/T/go-link-1689581912/go.o' has malformed LC_DYSYMTAB, expected 75 undefined symbols to start at index 6656, found 84 undefined symbols starting at index 53 |
Change https://go.dev/cl/461697 mentions this issue: |
Change https://go.dev/cl/511355 mentions this issue: |
@piusalfred that is just a warning, not an error. You should still get a binary. Does the binary run? If not, see #61190, and post on that issue if you have any update. Thanks! |
The non-PIE binary crash (#61229 (comment)) is due to ld-prime silently ignores -no_pie flag and generates a PIE binary instead. But that doesn't work because in exe buildmode we assumed the binary is not relocated and so generated non-relocated addresses, which would not be correct if the binary is actually relocated. The CLs above handle it: 1. switch to PIE by default, 2. force ld64 in exe buildmode. (#61190 is not this. Still need to investigate.) |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as resolved.
This comment was marked as resolved.
/usr/local/go/pkg/tool/darwin_arm64/link: running clang failed: exit status 1 |
@cobo-louis could you share the program you are building and the steps to reproduce the failure? Then we can report it to Apple. This is a bug in Apple's new linker. Thanks. |
The warning on the race C object (the syso file) is due to this code in LLVM TSAN:
Apparently, on Darwin, that caused the object to include weird symbols like (
They are "undefined" symbols but have values (unlike all other UND symbols). And apparently the new Apple linker doesn't like them and warns. If I comment those three lines off, it no longer generates those symbols and no more warnings from the linker. On Darwin, at assembler level, all C symbols are prefixed by
on Darwin? |
Hi, I am trying to install a cli package but i receive the following error and the package is not installed: ➜ ~ go install github.com/ethereum/go-ethereum/cmd/abigen@latest
# github.com/ethereum/go-ethereum/cmd/abigen
ld: warning: '/private/var/folders/nh/78bdkps97rv6pdws74j1xy0w0000gn/T/go-link-1841817092/go.o' has malformed LC_DYSYMTAB, expected 121 undefined symbols to start at index 30647, found 165 undefined symbols starting at index 96 I am not sure how this is xcode related however I used xcode before. Any help appreciated. |
Try adding that env var: #61229 (comment) before running |
Still seeing those warnings on 1.22 installed today on a Sonoma 14.3.1 M1. |
Thank you for the suggestion @nebiros, but unfortunately setting the env var only hid the warning and the package was still not installed.
@cherrymui i was using 1.20.6, but today i upgraded to 1.22.0 and the warning is gone and i was able to install the package as well. Not sure if it's just a local issue or related to the actual go version. Thanks anyway. |
I've been able to reproduce the "malformed LC_DYSYMTAB" warning on my Macbook Pro M2 Max running Sonoma 14.3.1 and go 1.22.1. I do not see the warning at all when using go 1.21.8. The best reproducible test case I've been able to come up with is running tests on https://github.com/DataDog/zstd , ref 869dae002e5efb372a0b09cd7d99390ca2089cc1:
When I fully remove the C code and edit the Go code to not use the C package, the warning is not present. Unfortunately, I'm unable to figure out what about the C code is causing this problem. |
@wendorf as mentioned above #61229 (comment) , the warning is for the C code in the race detector (LLVM TSAN) itself. The only difference that user C code made is that it changes the default link mode. Without user C code, the Go linker by default does all the linking itself, without using the C linker (Apple's linker). When user C code is present, it uses the C linker by default. You can try passing |
A note about the
The warning on the race detector C object is not really a bug in Go. Maybe we can fix in the upstream TSAN (also see #61229 (comment)). To work around, you could try
Thanks. |
Hello @nebiros, I reproduced your problem with the linker warning highlighted as an error in GoLand. The reason why the warning is displayed in red is that the linker message is being written to stderr. This is a highlighting problem and it shouldn't affect the build process in any way. |
That would explain why GoLand marked those tests as failed. I don't think this is a nice behaviour, warnings shouldn't be posted to stderr, it's reasonable for other applications to assume anything on stderr is an error. |
I think this is a different problem, GoLand shouldn't mark tests as failed due to extra output. Can you please describe how to reproduce this issue? Here or in the comments to GO-16873. |
@h31 I know it doesn't affect the build process, but I wasn't talking about that, I was talking about testing and running unit tests:#61229 (comment), those warnings mark tests as failed, so it breaks all tests |
NOTE -- please read
If you see lines starting with
ld: warning
but not other outputs, they are just warnings, not errors. You should still get a working binary, if there is no other output. Please only report if you see a link error, or a broken binary, or a warning that is not mentioned in the "warnings" section below. Thanks.See #61229 (comment) for more notes about
malformed LC_DYSYMTAB
warning. Thanks.In Xcode 15 beta it comes with Apple's new linker, ld-prime. As of beta 3 it is enabled by default. I did some experiments and found some issues for Go (cgo) with the new Apple linker. Some of the issues are reported in #61190. I'm filing a new issue to track all related faulures.
warnings
Apparently the new linker is more picky. It issues some warnings that the old linker (ld64) doesn't. This includes
These are just warnings and don't affect the correctness of the build. I'm preparing CLs for fix/work around them.
offset/addend being dropped
Mostly for c-archive, c-shared, and plugin build mode, for some relocations it seems the offset/addend being dropped and the relocation is resolved to the beginning of the section. This may cause failures like SIGILL. E.g.
#60694 is the same failure mode.
debug info issues
The new linker doesn't generate stab symbols for our functions, causing debug info being lost. Failure look like
There is also issues with combining DWARF into executable/shared object. Currently it is affecting c-shared build mode. ld-prime rejects the shared object if we add a DWARF segment to it.
non-PIE build doesn't work (Intel Mac only)
The new linker silently ignores the -no_pie flag and generates a PIE binary, which won't work because we assumed some addresses are not relocated. CL https://go.dev/cl/461697 changes the default to PIE and CL https://go.dev/cl/511355 contains a workaround if we are asked to build a non-PIE binary.
fixes/workarounds
CL https://golang.org/cl/505415 and the stack, as well as other CLs linked in this issue, contain tentative fixes and workarounds that address some of the issues. I'll also work with Apple to have them addressed on their side.
I'm hoping o have them addressed before Apple's new linker is finally released.
The text was updated successfully, but these errors were encountered: