From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11571 invoked by alias); 22 Dec 2004 02:44:44 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 11543 invoked by uid 48); 22 Dec 2004 02:44:39 -0000 Date: Wed, 22 Dec 2004 02:44:00 -0000 Message-ID: <20041222024439.11542.qmail@sourceware.org> From: "amodra at bigpond dot net dot au" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040922123524.17608.schwab@suse.de> References: <20040922123524.17608.schwab@suse.de> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/17608] [3.3.4/3.4/4.0 regression] -profile should prevent use of libgcc_s X-Bugzilla-Reason: CC X-SW-Source: 2004-12/txt/msg03151.txt.bz2 List-Id: ------- Additional Comments From amodra at bigpond dot net dot au 2004-12-22 02:44 ------- On investigating, I'm convinced this is a linker bug. When linking we use: -lgcc --as-needed -lgcc_s --no-as-needed -lc_p -lgcc --as-needed -lgcc_s --no-as-needed. During the first scan of libgcc_s.so, the linker finds no reason to mark libgcc_s.so as needed, because no symbols in libgcc_s.so are referenced at that point. After linking libc_p.a, the second scan of libgcc_s.so does find referenced symbols. However, the linker sees that these symbols have already been defined, thus the "new" definitions found in the second scan of libgcc_s.so aren't used. (If a symbol is defined in two shared libs, the one from the lib first encountered by the linker is used. As far as the linker is concerned the first libgcc_s.so is a different shared lib from the second libgcc_s.so). Thus the linker decides that the second libgcc_s.so isn't needed, and so doesn't emit a DT_NEEDED tag for libgcc_s.so. With older glibc ld.so, this resulted in segfaults. Current ld.so complains with Inconsistency detected by ld.so: dl-version.c: 230: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17608