-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/go: "#cgo pkg-config:" comments do not work with gccgo #11739
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
Comments
The pkg-config flags are implemented by cmd/go, not cmd/cgo. The code does seem to be independent of the compiler toolchain; I don't know why it's not working for gccgo. |
Well, pkg-config is called by cmd/go sure, but the way the flags get used seems to be a cgo / cmd/compile / cmd/link collaboration: go calls pkg-config, passes the results to cgo as CGO_LDFLAGS in the environment, cgo writes them as cgo_ldflags comments to one of the .go files it creates, cmd/compile translates those to the "$$ // cgo" section of the .o file, which is read by cmd/link and passed to the external linker. Only the first two bits happen when using gccgo. I don't know what a fix would look like. The go tool could somehow stuff some record of the flags into the .a of a cgo using package and look for it again when linking? Currently I don't think it actually looks into the lib$name.a files at all but I guess that could change... |
Can someone assign this to me please? |
I've hit this as well. Any status update? |
Not really -- I definitely want to get this fixed for 1.6 but haven't started on it myself, or even thought very hard about how to fix it (the only thing I've thought is to have the go tool put the the flags into the .a file of a package using cgo and reading them out when linking) |
Should not this have been fixed by https://codereview.appspot.com/157460043/ ? That's about a year old, so maybe something else broke? |
No that fixed the worst of the problems in the area, but this one is different: pkg-config is run when the go package is compiled, but the flags must be used when the executable is linked, which might not be in the same invocation of the go tool. |
This would be nice but I don't see this happening for Go 1.6. |
Yeah, didn't get to this :/ |
CL https://golang.org/cl/18790 mentions this issue. |
DO NOT SUBMIT This is too late for Go 1.6 but we'd like to get a fix into Ubuntu (as a distro patch) so a review would be appreciated. The unique difficulty of #cgo pkg-config is that the linker flags are recorded when the package is compiled but (obviously) must be used when the package is linked into an executable -- so the flags need to be stored on disk somewhere. As it happens cgo already writes out a _cgo_flags file: nothing uses it currently, but this change adds it to the lib$pkg.a file when compiling a package, reads it out when linking (and passes a version of the .a file with _cgo_flags stripped out of it to the linker). It's all fairly ugly but it works and I can't really think of any way of reducing the essential level of ugliness. Fixes golang#11739 Change-Id: I35621878014e1e107eda77a5b0b23d0240ec5750
Copy of https://golang.org/cl/18790 by Michael Hudson-Doyle. The unique difficulty of #cgo pkg-config is that the linker flags are recorded when the package is compiled but (obviously) must be used when the package is linked into an executable -- so the flags need to be stored on disk somewhere. As it happens cgo already writes out a _cgo_flags file: nothing uses it currently, but this change adds it to the lib$pkg.a file when compiling a package, reads it out when linking (and passes a version of the .a file with _cgo_flags stripped out of it to the linker). It's all fairly ugly but it works and I can't really think of any way of reducing the essential level of ugliness. Update golang/go#11739. GCC PR 66904. Change-Id: I1354c8b65749865d3323998094670e61a8b091a6 Reviewed-on: https://go-review.googlesource.com/19431 Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/go: fix "#cgo pkg-config:" comments with gccgo Copy of https://golang.org/cl/18790 by Michael Hudson-Doyle. The unique difficulty of #cgo pkg-config is that the linker flags are recorded when the package is compiled but (obviously) must be used when the package is linked into an executable -- so the flags need to be stored on disk somewhere. As it happens cgo already writes out a _cgo_flags file: nothing uses it currently, but this change adds it to the lib$pkg.a file when compiling a package, reads it out when linking (and passes a version of the .a file with _cgo_flags stripped out of it to the linker). It's all fairly ugly but it works and I can't really think of any way of reducing the essential level of ugliness. Update golang/go#11739. GCC PR 66904. Reviewed-on: https://go-review.googlesource.com/19431 git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@233290 138bc75d-0d04-0410-961f-82ee72b054a4
This updates gccgo to the final version of https://golang.org/cl/18790, by Michael Hudson-Doyle. Update golang/go#11739. Change-Id: I66b42d6dbe6ed2ea8b0e7cbdd1ff211704811614 Reviewed-on: https://go-review.googlesource.com/22400 Reviewed-by: Ian Lance Taylor <iant@golang.org>
This updates gccgo to the final version of https://golang.org/cl/18790, by Michael Hudson-Doyle. Update golang/go#11739. Reviewed-on: https://go-review.googlesource.com/22400 git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@235380 138bc75d-0d04-0410-961f-82ee72b054a4
I don't have a minimal example, but https://launchpadlibrarian.net/211688868/buildlog_ubuntu-wily-arm64.account-polld_0.1%2B15.04.20150410-0ubuntu2~gcc5.1_BUILDING.txt.gz is an example of this happening. http://bazaar.launchpad.net/~ubuntu-push-hackers/account-polld/trunk/view/head:/accounts/accounts.go#L20 is "#cgo pkg-config: glib-2.0 libaccounts-glib libsignon-glib" but the flags are not being passed in the link.
I don't entirely get how this is supposed to work. cgo writes the flags to a file:
but afaict nothing ever looks at this file. When *gccgo is false (https://github.com/golang/go/blob/master/src/cmd/cgo/out.go#L42) it also writes out //go:cgo_ldflag comments, which is how this works with the usual compiler but gccgo doesn't use those comments I think.
The text was updated successfully, but these errors were encountered: