From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13436 invoked by alias); 15 May 2005 18:43:39 -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 13425 invoked from network); 15 May 2005 18:43:35 -0000 Received: from unknown (HELO sadr.equallogic.com) (66.155.203.134) by sourceware.org with SMTP; 15 May 2005 18:43:35 -0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j4FIhZZd006477 for ; Sun, 15 May 2005 14:43:35 -0400 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j4FIhWNd006472; Sun, 15 May 2005 14:43:32 -0400 Received: from pkoning.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id j4FIhU524078; Sun, 15 May 2005 14:43:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17031.38996.793456.366778@gargle.gargle.HOWL> Date: Sun, 15 May 2005 19:44:00 -0000 From: Paul Koning To: amodra@bigpond.net.au Cc: drow@false.org, binutils@sources.redhat.com Subject: Re: Unintellegible ld error messages References: <17026.22346.789514.57742@gargle.gargle.HOWL> <20050511191110.GA470@nevyn.them.org> <17029.942.76640.325068@gargle.gargle.HOWL> <20050513195035.GA19560@nevyn.them.org> <17029.2332.365233.194854@gargle.gargle.HOWL> <20050514015015.GC27573@bubble.grove.modra.org> X-SW-Source: 2005-05/txt/msg00495.txt.bz2 >>>>> "Alan" == Alan Modra writes: Alan> On Fri, May 13, 2005 at 04:07:56PM -0400, Paul Koning wrote: >> It turns out that libgcc.so has _Unwind_GetIP as a regular symbol, >> but libgcc.a has it as a hidden symbol. One of my builds only has >> the .a version of libgcc, so that's why that link fails (while >> others for another target work fine). Alan> _Unwind_GetIP as a hidden symbol in libgcc.a is not the Alan> problem. If you built libstdc++.so linked against libgcc_s.so, Alan> then when linking using libstdc++.so you need to have Alan> libgcc_s.so available, and, importantly, libgcc_s.so must be Alan> linked before libgcc.a if both are specified. Alan> If you built libstdc++.so only linked against libgcc.a, then Alan> you can use libstdc++.so like that too. Interesting. objdump says that libstdc++ requires libm, but not libgcc_s. And libm doesn't require anything. paul