-
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: missing references to symbols in .syso #52863
Comments
cc @golang/runtime Hard to say without investigating if this is a new bug in the compiler or a latent bug in gioui. |
What is in the syso and how is it built? It looks like those symbols are from C libraries. |
cc @eliasnaur |
it seems the build is taken care of by: https://git.sr.ht/~eliasnaur/gio-shader/tree/main/item/piet/gencpu.sh the program that actually creates the |
Does |
|
Timed out in state WaitingForInfo. Closing. (I am just a bot, though. Please speak up if this is a mistake or you have the requested information.) |
Reopening because I'm seeing this, too. |
I'm seeing slightly different behavior, where
Adding
|
Thanks @dominikh for the information. It seems the error comes from this command
which is the cgo tool building _cgo_main.c, instead of the final linking of the binary. CL https://go-review.googlesource.com/c/go/+/402596 may be related, which makes the cgo tool pass syso files. It appears that when compiling the |
We did not expect to see packages use .syso files that depend on code defined by the package. We expected .syso files to stand alone, or at least to only depend on other .syso files. The problematic link is only required when internal linking mode. I wonder how much would break if we required some new |
I wonder if we can do that link step at (Go) link time. At that point, we know what link mode we use. If we use external linking, we don't need to run it. If we use internal linking, we only need that information at link time. And presumably we can run it just once for a binary, instead of once for each cgo-using packages. At that point we could probably pull in all the C code together. (Of course that would need a lot of work for the go command, and perhaps the cgo tool.) |
I think I have a relatively simple solution: if cgo fails when generating |
SGTM. Thanks. |
Working on it. |
Change https://go.dev/cl/413460 mentions this issue: |
For a package that uses cgo, the file _cgo_import.go is created to record information required for internal linking: the non-Go dynamic symbols and libraries that the package depends on. Generating this information sometimes fails, because it can require recreating all the dependencies of all transitively imported packages. And the information is rarely needed, since by default we use external linking when there are packages outside of the standard library that use cgo. With this CL, if generating _cgo_import.go fails, we don't report an error. Instead, we mark the package as requiring external linking, by adding an empty file named "dynimportfail" into the generated archive. If the linker sees a file with that name, it rejects an attempt to use internal linking. Fixes golang#52863 Change-Id: Ie586e6753a5b67e49bb14533cd7603d9defcf0ea Reviewed-on: https://go-review.googlesource.com/c/go/+/413460 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
everything works fine w/ Go-1.18.x
What did you expect to see?
a valid build.
The text was updated successfully, but these errors were encountered: