cmd/go: generating C header files for transitive dependencies is awkward #35715
Comments
One possibility might be to add another That could be used as a more direct substitute for the |
Another option might be to make the |
Change https://golang.org/cl/208117 mentions this issue: |
Change https://golang.org/cl/208119 mentions this issue: |
We could have |
Maybe, but the import itself seems like a bit of a non-sequitur: if the C code is using identifiers from package On the other hand, I suppose that the C library must link against some (shared or archive) file generated from a |
Also add a -testwork flag to facilitate debugging the test itself. Three of the tests of this package invoked 'go install -i -buildmode=c-archive' in order to generate an archive as well as multiple C header files. Unfortunately, the behavior of the '-i' flag is inappropriately broad for this use-case: it not only generates the library and header files (as desired), but also attempts to install a number of (unnecessary) archive files for transitive dependencies to GOROOT/pkg/$GOOS_$GOARCH_shared, which may not be writable — for example, if GOROOT is owned by the root user but the test is being run by a non-root user. Instead, for now we generate the header files for transitive dependencies separately by running 'go tool cgo -exportheader'. In the future, we should consider how to improve the ergonomics for generating transitive header files without coupling that to unnecessary library installation. Updates #28387 Updates #30316 Updates #35715 Change-Id: I3d483f84e22058561efe740aa4885fc3f26137b5 Reviewed-on: https://go-review.googlesource.com/c/go/+/208117 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
The tests in this package invoked 'go install -i -buildmode=c-shared' in order to generate an archive as well as multiple C header files. Unfortunately, the behavior of the '-i' flag is inappropriately broad for this use-case: it not only generates the library and header files (as desired), but also attempts to install a number of (unnecessary) archive files for transitive dependencies to GOROOT/pkg/$GOOS_$GOARCH_testcshared_shared, which may not be writable — for example, if GOROOT is owned by the root user but the test is being run by a non-root user. Instead, for now we generate the header files for transitive dependencies separately by running 'go tool cgo -exportheader'. In the future, we should consider how to improve the ergonomics for generating transitive header files without coupling that to unnecessary library installation. Updates #28387 Updates #30316 Updates #35715 Change-Id: I622426a860828020d98f7040636f374e5c766d28 Reviewed-on: https://go-review.googlesource.com/c/go/+/208119 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Any movement on this? I'm trying the workaround suggested by bcmills@ of using
where both I'd like to define a type alias If I define the alias in If I define the same alias in |
As discovered in CL 208117 (#30316),
cmd/go
(as of Go 1.14) lacks a good way to generate C header files for Go libraries in order to use them from C.go install -buildmode=c-archive
andgo install -buildmode=c-shared
will, as a side-effect, generate header files for the requested package. However,-buildmode=c-archive
and-buildmode=c-shared
today require the named package to be apackage main
, and those commands do not generate headers for the (transitive) Go dependencies of the named package.The
-i
flag does generate headers for transitive dependencies, but it also has a second, unwanted side effect: it builds (and attempts to install) libraries for the transitive dependencies of the named package, including transitive dependencies in the standard library. That fails if the user cannot write toGOROOT/pkg
, such as when a non-root user is working with ago
tool installed as root.As a workaround, one can run
go tool cgo -exportheader
, butgo tool cgo
accepts a list of files rather than a list of packages, and generates a number of additional outputs (normally in an_obj
subdirectory) that the C caller does not directly need. So we're still doing extra work, just in a different location.We should see what we can do to make it easier to generate C headers without unnecessary or unwanted side-effects.
CC @ianlancetaylor @jayconrod
The text was updated successfully, but these errors were encountered: