https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134
--- Comment #5 from boger at us dot ibm.com ---
(In reply to Tatsushi Inagaki from comment #0)
Created attachment 34813 [details]
Example to reproduce the constructor problem
Gccgo ignores a C-function with the constructor attribute in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134
--- Comment #6 from Ian Lance Taylor ian at airs dot com ---
No, I believe the problem is different. The gccgo build process stores objects
in an archive, and relies on the system linker to pull in those objects.
However, at least on ELF-based
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134
--- Comment #1 from Ian Lance Taylor ian at airs dot com ---
It's pretty ugly, but a workaround is to drop something like this into sub.go:
var AlwaysFalse bool
func init() {
if AlwaysFalse {
C.init()
}
}
The idea is to force in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134
--- Comment #2 from Tatsushi Inagaki e29253 at jp dot ibm.com ---
(In reply to Ian Lance Taylor from comment #1)
It's pretty ugly, but a workaround is to drop something like this into
sub.go:
var AlwaysFalse bool
func init() {
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134
--- Comment #3 from Ian Lance Taylor ian at airs dot com ---
In principle, sure. In practice, since it's an exported variable, the compiler
would have to see the entire program, which can't happen at present. If it
ever can, then something else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134
--- Comment #4 from Tatsushi Inagaki e29253 at jp dot ibm.com ---
I see. Thanks a lot!
