On Mon, Jan 12, 2009 at 2:25 PM, Dave Korn <[email protected]> wrote:
> Yep. It particularly shows up on win32 because i) all references have to > be resolved at final link time in an executable - perhaps by reference to a > DLL, but they can't just be left dangling to be filled in at runtime by the > loader as they can in ELF formats - and ii) we tend to do static linking on > win32, so where the order of libs is wrong on the command-line we get > unresolved references (which then cause link failure, rather than being > resolved at runtime). > > The big problem however is libstdc++ vs. bootstrap. If PPL links against > libstdc++, and is part of the core C compiler, then we have to have libstdc++ > available during the early part of each stage when we build the core compiler > - but the only libstdc++ available is the system's one. > > Roberto, what does ldd show on the various cc1 binaries in the different > stage directories of your most recent bootstrap? I'm guessing you'll see that > the stage 2 cc1 is linked against the system libstdc++ rather than the > newly-bootstrapped one. I encountered this on AIX as well prior to recompiling GMP as a shared library. libppl references libstdc++ and libgmpxx. libgmpxx references libstdc++. libcloog and cc1 do not reference libstdc++. David
