[Bug go/65134] gccgo ignores the attribute "constructor" in a subdirectory

[ian at airs dot com]

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 systems like GNU/Linux, the system linker does
not link an object from an archive merely because it has a constructor.  It
only links an object from an archive if there is some reference to it: if the
object defines a symbol that some other object, already included in the link,
refers to.  What I'm doing with the Go code is adding a reference, forcing the
object to be linked in from the archive.

Once the object is linked in, everything works.  So although we want the
reference, we don't want the reference to actually do anything.  That is why I
wrote the AlwaysFalse code: so that there is a function call, but the compiler
can't see that the function will never be called.

This is a standard problem with ELF linkers.  See, e.g.,
http://stackoverflow.com/questions/6589772/gcc-functions-with-constructor-attribute-are-not-being-linked
.  This issue is not really Go-specific, except for the fact that the go tool
build process when using gccgo uses archives.  Perhaps it should change to work
in some other way.