From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25817 invoked by alias); 31 Jan 2005 21:22:19 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 25676 invoked from network); 31 Jan 2005 21:22:04 -0000 Received: from unknown (HELO sccrmhc12.comcast.net) (204.127.202.56) by sourceware.org with SMTP; 31 Jan 2005 21:22:04 -0000 Received: from lucon.org ([24.6.212.230]) by comcast.net (sccrmhc12) with ESMTP id <2005013121220301200ge39fe>; Mon, 31 Jan 2005 21:22:03 +0000 Received: by lucon.org (Postfix, from userid 1000) id 6443A63FD1; Mon, 31 Jan 2005 13:22:03 -0800 (PST) Date: Mon, 31 Jan 2005 21:22:00 -0000 From: "H. J. Lu" To: binutils@sources.redhat.com Cc: amodra@bigpond.net.au Subject: ELF linker is broken Message-ID: <20050131212203.GA27701@lucon.org> References: <20050130192249.GA21997@lucon.org> <20050131000227.GF11595@bubble.modra.org> <20050131071308.GH11595@bubble.modra.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <20050131071308.GH11595@bubble.modra.org> User-Agent: Mutt/1.4.1i X-SW-Source: 2005-01/txt/msg00567.txt.bz2 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1876 On Mon, Jan 31, 2005 at 05:43:08PM +1030, Alan Modra wrote: > On Mon, Jan 31, 2005 at 10:32:27AM +1030, Alan Modra wrote: > > On Sun, Jan 30, 2005 at 11:22:49AM -0800, H. J. Lu wrote: > > > /usr/lib/crt1.o:(.dynamic+0x0): multiple definition of `_DYNAMIC' > > [snip] > > > The 2005-01-24 binutils is OK. It may have something to do with > > > > > > http://sources.redhat.com/ml/binutils/2005-01/msg00405.html > > > > Possible, I suppose. An as-needed shared lib will define syms whether > > or not the lib is actually linked. It will be linked if any symbol it > > defines satisfies an undefined reference, and conversely it isn't linked > > then there are no references to its symbols. That should make it safe > > to leave its symbols in the symbol table, so long as we properly treat > > them in _bfd_elf_merge_symbol. If there is a problem, it's likely to be > > in _bfd_elf_merge_symbol. > > I'm testing the following on powerpc and x86 to ensure I haven't made > any silly mistakes. It's a big hammer approach but cleaner than what we > had before, I think. Rather than tweaking _bfd_elf_merge_symbol and > other places to specially handle symbols defined in unused --as-needed > libs, I've munged all such symbols back to their new state. Hopefully > this won't break too many back-end elf_link_hash_traverse functions.. > > Would you please test this on ia64? I don't have access to ia64 > hardware, so testing this isn't so easy. I am enclosing a testcase here. I saw the same problem on ia32, ia64 and x86_64: [hjl@gnu-4 needed]$ make gcc -c -o foo.o foo.c gcc -shared -fPIC -o libneeded.so needed.c gcc -o foo foo.o \ -Wl,--as-needed -lneeded -L. -Wl,--no-as-needed /usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/../../../crt1.o:(.dynamic+0x0): multiple definition of `_DYNAMIC' collect2: ld returned 1 exit status make: *** [foo] Error 1 H.J. --9jxsPFA5p3P2qPhR Content-Type: application/x-gzip Content-Disposition: attachment; filename="bug.tar.gz" Content-Transfer-Encoding: base64 Content-length: 480 H4sIALeg/kEAA+3VzWrCQBQF4Gxzn+IuFFSaMDF/YCkUsipU6K6bUogx0bRj BhLtwtJ374zG2m7qKhbp+RZm8F5nBicnmaaveVHK3OqQ8ISIgsASWhz9vBq+ H1ie8OI4HItxFJr+KBQWiy43dbBp1mnNbC1f5K99p+oXKkluFllGlEo54UIp Iv2xG7mKZTmr8nyez91Gkd0bJMmQHcW927b+RLbtPMorx0kbZ9/JjjwM7l3e Fyt1rBPpSft6vgn33exr0maZ1uY3xcNd0i7ReybKZJ5WE7LrlS7xSC85Mlsh fWT6W3NwWbHl2Wbh6rG72PK0vZ11X0Z//d9eAnOQWcdrnMq/+JZ/L4pNv+eH yP85lNWaVmlZ8WBI78Rc5+tNXbG4pg/k5x9on++dPgJO5n8s2vx7se/t8h/G AfJ/Dm+qnJtX/j7/yDwAAAAAAAAAAAAAAAAAwKX6BBqUKJEAKAAA --9jxsPFA5p3P2qPhR--