On 01/28/13 16:07, David Edelsohn wrote: > On Mon, Jan 28, 2013 at 4:07 AM, Michael Haubenwallner > <michael.haubenwall...@salomon.at> 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/
