[PPL-devel] Graphite/Cloog/PPL problems on Cygwin, HEAD broken maybe?

Dave Korn dave.korn.cygwin at googlemail.com
Mon Jan 12 20:25:33 CET 2009


Joseph S. Myers wrote:
> On Mon, 12 Jan 2009, Roberto Bagnara wrote:
>
>> I am not sure I understand the question (and I am not familiar with Cygwin).
>> The answer to the question "Why is there C++ in my libppl" is that libppl
>> is written in C++.  The C interface to the PPL, libppl_c, is also written
>> in C++.  Your description of the problem confuses me, as it seems to be
>> system-independent;  however, I have no problems bootstrapping HEAD on my
>> GNU/Linux system.  What am I missing?
>
> Try bootstrapping with only static versions of all the relevant libraries
> (GMP including C++ interface, PPL, libstdc++ etc.).  I believe that is the
> issue here - all libraries must be listed in the right order when linking
> GCC, including -lstdc++, rather than relying on shared library
> dependencies.
>

  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.

    cheers,
      DaveK



More information about the PPL-devel mailing list