From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43683 invoked by alias); 24 Feb 2015 17:24:59 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 43613 invoked by uid 48); 24 Feb 2015 17:24:54 -0000 From: "ian at airs dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug go/65134] gccgo ignores the attribute "constructor" in a subdirectory Date: Tue, 24 Feb 2015 19:02:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: go X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ian at airs dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ian at airs dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-02/txt/msg02683.txt.bz2 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/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.