On Mon, Jan 12, 2009 at 2:25 PM, Dave Korn dave.korn.cygwin@googlemail.com 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