-
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/go: allow cross-compiling with cgo #5848
Labels
Milestone
Comments
I'm sorry but I don't understand the issue you have raised. As I understand it you are trying to cross compile from linux/amd64 to linux/arm, specifically for an older ARMv5 based host. As I also understand, gosqlite requires cgo. It is currently not possible to cross compile a binary that requires cgo. Can you please restate the issue that you are seeing. Status changed to WaitingForReply. |
Yes, you understand the problem correctly. Why it is not possible to cross-compile a binary that requires cgo? I was able to cross-compile runtime/cgo and gosqlite package manually without using 'go build' and it works fine, so the problem is only with the 'go build' tool. Maybe I'll try to fix this bug and send a patch. |
Fixed by reverting revision 139b5fe32880 (issue #5141) and setting correct CC environment variable, since cmd/go nowadays don't have 'gcc' harcoded and respects environment. Better to fix this in upstream. |
it is the issue tracker of the upstream. :-) anyway, technically fixing this issue isn't hard (in fact, all required functionality is there, just remove the restriction in cmd/go). the hard part is the documentation as cross compiling has many caveats. we will need a whole new document page about cross compiling with Go. |
I'm working on cross-compiled Go project now (collecting some toolchain bugs :) and really enjoying the language; so maybe I'll write a short 'go cross-compile howto" article. What caveats do you mean? Usually, setting some environment variables with correct paths to toolchain, compiler/linker flags, include & lib dirs, etc is enough in case of traditional GNU toolchain. There may be go-specific pitfalls, but fixing and/or documenting them is just a question of time. IMHO, this discussion goes beyond the issue tracker format. |
Merged into issue #4714. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by lexszero:
The text was updated successfully, but these errors were encountered: