From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5534 invoked by alias); 30 Jan 2013 11:35:36 -0000 Received: (qmail 5522 invoked by uid 22791); 30 Jan 2013 11:35:36 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.salomon.at (HELO smtp.salomon.at) (193.186.16.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 30 Jan 2013 11:35:30 +0000 Received: from samail03.wamas.com ([172.28.2.2] helo=mailhost.salomon.at) by smtp.salomon.at with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1U0Vwq-0004UG-Lu; Wed, 30 Jan 2013 12:35:25 +0100 Received: from [172.28.8.170] by mailhost.salomon.at with esmtp (Exim 4.77) (envelope-from ) id 1U0Vwq-0007ZY-J3; Wed, 30 Jan 2013 12:35:24 +0100 Message-ID: <5109057C.3090800@salomon.at> Date: Wed, 30 Jan 2013 11:35:00 -0000 From: Michael Haubenwallner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120327 Thunderbird/10.0.3 MIME-Version: 1.0 To: David Edelsohn CC: GCC Patches Subject: Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld References: <5100FC73.8090300@salomon.at> <51028EC7.1070807@salomon.at> <51063FCD.7010802@salomon.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-01/txt/msg01426.txt.bz2 On 01/28/13 16:07, David Edelsohn wrote: > On Mon, Jan 28, 2013 at 4:07 AM, Michael Haubenwallner > wrote: > >> But still curious if you've been able to reproduce the problem, >> and why you didn't encounter this problem beforehand. > > As I mentioned before, because of --boot-ld-flags, with earlier libgcc > and libstdc++ installed in that directory. But why didn't the RPATH_ENVVAR=LD_LIBRARY_PATH break for you when libatomic is configured (in stage3) for ppc64 because of this workflow I can see there: 1: gcc/xgcc is linked by prev-gcc/xg++ 1.1: against *dynamic* libstdc++.a 1.2: from prev-powerpc-ibm-aix7.1.0.0/libstdc++-v3/src/.libs/, 1.3: which is stored as runpath. 2: For a target-library (libstdc++, libatomic, ...), and for each multilib-variant (32/64, pthread yes/no) 2.1: LD_LIBRARY_PATH is set to that multilib variant's libstdc++.a dir 3: So LD_LIBRARY_PATH points to ppc64/libstdc++-v3/.libs/ while using 32bit gcc/xgcc to build 64bit libstdc++.a. => This does /not/ break, as that libstdc++.a is not there yet. 4: Also, LD_LIBRARY_PATH points to ppc64/libstdc++-v3/.libs/ while using 32bit gcc/xgcc to build libatomic.a. => This is the one that /does/ break, as that 64bit libstdc++.a is there now. The only situation of wich I can think of not breaking here would be: * --boot-ldflags are first on the linkline, and * libstdc++.a found there is static only. Or what important thing I could have missed? Thanks! /haubi/