-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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/cgo: link error on OS X (unsupported scattered relocation) #3253
Labels
Comments
Marking this Priority-Go1 for now, but more a hope than a promise. Labels changed: added priority-go1, removed priority-triage. Owner changed to builder@golang.org. Status changed to Accepted. |
It also happens for me on 10.6 386 (latest tip: 885465912b99). It looks to be an issue with extern pointers, in the simple example I have provided, an extern int works fine, but an extern *int doesn't. I'm fairly certain this only happens when ld is trying to link gcc compiled code statically, since we would have run into this problem with most cgo libraries otherwise. I think this issue is relatively high priority since it seems to affect all darwin builds, and makes providing custom C-code to packages (that can be built trivially with the go tool) a potential minefield for portability. Attachments:
|
I'm the author of that termbox library btw. Just tried to make it work on MacOSX and succeeded (thanks goes to LeNsTR for providing me with ssh access to his Mac machine). It seems that adding "-fno-common" flag to cgo gcc files (when compiling, not linking) does the job. The reason why it works is a mistery to me. |
-fno-common affects the placement and initialization of global variables (see: http://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Code-Gen-Options.html). There seems to be some bug in the 8l/6l linkers WRT mach-o files when statically linking files compiled with -fcommon (the default option). Unfortunately using "CGO_CFLAGS=-fno-common" doesn't solve the solution for me though, because for the above code, and in my own sample I now get: malformed mach-o file: unsupported scattered relocation 2/1 Which is an error similar to when I try to link to objective-c code (to interact with OSX) this is a known problem with go in Snow Leopard on 386 (the last version of OSX to support 386). Although the above problem (failing to link on Lion) could be solved by adding -fno-common to the link flags for all gcc compile tasks, this may result in trading one set of uncompilable code for another. |
To solve the specific issue of building your package on Lion (and most likely amd64 Darwin as well) -fno-common will work, and the user just has to build the code with: $ CGO_LDFLAGS="-fno-common" go install Which you can put in your README. I was able to solve the problem completely (no build errors) by moving all the code into a single *.c file and changing the 2 globals in question to be static instead of extern. But this would problably be unfeasible for most projects. |
That is probably the fastest solution, since the ammount of code it will break will probably be minimal, as it should only affect a small subset of GCC compiled Go files. There's still the situation that it leads to unsupported scattered relocation code which is a problem for the darwin/386 linker (not a Lion issue), and has no solution apart from code-rewrite. I think it might be good that this be documented somewhere because no matter how you solve it, short of fixing the linker, a package developer needs to know what they can try to do to solve the problem. Also, I see a better way to pass the flag than my earlier use of environment variables, use a cgo directive: // #cgo: darwin CFLAGS: -fno-common This way it requires no action on the part of users, and can be specified on a per-file basis if necessary. |
http://golang.org/cl/5822050/ Status changed to Started. |
Status changed to Duplicate. Merged into issue #1635. |
I reopened this bug, because fix for issue #1635 (rev bb2316abeea5) doesn't fix this issue on Mac OS X 10.7 http://build.golang.org/log/08f42de48d3118cc017a1bedd8daabca32ba318f Status changed to Accepted. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by ranveerkunal:
The text was updated successfully, but these errors were encountered: