On Wed, Jan 30, 2013 at 6:35 AM, Michael Haubenwallner <michael.haubenwall...@salomon.at> wrote:
> 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? Originally, I was using --boot-ld-flags which included /usr/gnu/lib first in the path, so an older version of libstdc++ was found. Now, after your patch, cc1plus is statically linked with libstdc++.a. - David
