-
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: Conflicting types for generated symbols prevent LTO-enabled compilation #43830
Comments
Currently, cgo declares different types for exported symbols between _cgo_main.c and _cgo_export.c. This is not compatible with link time optimization in GCC and causes builds to fail when compiling with CGO_CFLAGS="-flto -ffat-lto-objects". This commit appends -fno-lto to the cflags when building _cgo_export.c to disable link time optimization locally on the built object. Fixes golang#43830
Currently, cgo declares different types for exported symbols between _cgo_main.c and _cgo_export.c. This is not compatible with link time optimization in GCC and causes builds to fail when compiling with CGO_CFLAGS="-flto -ffat-lto-objects". This commit appends -fno-lto to the cflags when building _cgo_export.c to disable link time optimization locally on the built object. Fixes golang#43830
Change https://golang.org/cl/292990 mentions this issue: |
Change https://golang.org/cl/293290 mentions this issue: |
This patch fixes another CGO related LTO bug. This seems to come when the programmer tries to assign a C function pointer to a local Go variable as seen in the reproducer. It turns out we do not need to emit _cgo_hack or our own definition of the symbol(s) within the _cgo_main.c file as was previously done. Fixes golang#43830
So I think the linked change is half right, basically. |
Change https://golang.org/cl/322614 mentions this issue: |
Change https://golang.org/cl/324009 mentions this issue: |
Change https://golang.org/cl/324010 mentions this issue: |
This permits the test to work in C99 mode. For #43830 Change-Id: Ide54bd62239cfe602e2664300f04e472df5daf43 Reviewed-on: https://go-review.googlesource.com/c/go/+/324009 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org>
Change https://golang.org/cl/324049 mentions this issue: |
These tests pass or fail depending on the exact compiler version, which the TestScript tests don't support. Rewrite into Go. For #43830 For #46295 Change-Id: I91b61dfe329d518e461ee56f186f0e9b42858e77 Reviewed-on: https://go-review.googlesource.com/c/go/+/324049 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
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?
Enable link time optimization CFLAGS when building a Go program containing an
//export
directive.The above program builds normally using
go build
without additional CFLAGS. However, building withCGO_CFLAGS='-flto -ffat-lto-objects' go build
produces the following error.This is due to the same symbol name being used in separate contexts as both a function and an integer.
What did you expect to see?
Program builds when enabling link time optimization via CFLAGs.
What did you see instead?
Generated intermediate C code for
//export
is incompatible with link time optimization.Notes
Additional conflicting symbols may be created if the program binds the value of an exported function's C handle to a Go variable. The following program demonstrates the behavior.
When built with
CGO_CFLAGS='-flto -ffat-lto-objects' go build
, the linker yields the following error.The interesting aspect to note is the redeclaration of the
add
symbol in addition to the previously encountered_cgoexp*_add
symbol. This comes from introducing the assignment statement ofC.add
to the variablefn
, and causes cgo to emit an additional pair of matching symbols with conflicting types via another code path.The text was updated successfully, but these errors were encountered: