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 #6 from Ian Lance Taylor ---
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 systems like GNU/Lin
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134
--- Comment #4 from Tatsushi Inagaki ---
I see. Thanks a lot!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134
--- Comment #3 from Ian Lance Taylor ---
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 would have to be do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134
--- Comment #2 from Tatsushi Inagaki ---
(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 AlwaysFalse {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134
--- Comment #1 from Ian Lance Taylor ---
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 something that refe
