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

[Sebastian Pop]

Hello Dave,

Thanks for testing Graphite on i686-pc-cygwin.

On Mon, Jan 12, 2009 at 9:52 AM, Dave Korn
<dave.korn.cygwin at googlemail.com> wrote:
>    Hi everyone,
>
>  HEAD isn't building for me right now.  Since I haven't tried building
> graphite-enabled GCC before, I may be doing something wrong, so I figured I'd
> ask questions before opening any PR.  (The actual questions are numbered for
> those who want to skip the detail.)
>
>  I followed the instructions at http://gcc.gnu.org/wiki/Graphite.  I'm using
> ppl-0.10 and a git clone of cloog from 2008-12-17.  I configured PPL:
>
> with options \"'-v' '--disable-shared' '--enable-static'
> '--prefix=/opt/gcc-tools' 'CC=gcc-4' 'CXX=g++-4' '--with-gnu-ld'\"
>
> and I configured CLOOG:
>
>  with options \"'-v' '--disable-shared' '--enable-static'
> '--with-ppl=/opt/gcc-tools' '--prefix=/opt/gcc-tools' 'CC=gcc-4' 'CXX=g++-4'
> '--with-gnu-ld'\"
>
> and part of the problem, at least, arises because I'm using static rather than
> shared libs; explained later.  I'm building native GCC HEAD on i686-pc-cygwin.
>
>  The three problems show up when linking cc1 at the end of each stage.
> Firstly, there's a multiply-defined symbol:
>
> ---------------------------<snip>---------------------------
> ranlib  libbackend.a
> gcc-4  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
> -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long
> -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -o
> cc1-dummy.exe c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o
> c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o
> c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o
> c-parser.o i386-c.o cygwin2.o msformat-c.o c-gimplify.o tree-mudflap.o
> c-pretty-print.o c-omp.o dummy-checksum.o \
>          main.o tree-browser.o libbackend.a ../libcpp/libcpp.a
> ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a -lintl -liconv
> ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/usr/lib -L/usr/lib
> -lmpfr -lgmp -L/opt/gcc-tools/lib -lcloog -L/opt/gcc-tools/lib -lppl_c -lppl
> -lgmpxx
> /opt/gcc-tools/lib/libcloog.a(domain.o): In function `debug_value':
> /gnu/gcc/prereq/cloog/source/ppl/domain.c:3579: multiple definition of
> `_debug_value'
> libbackend.a(graphite.o):/gnu/gcc/gcc/gcc/graphite.c:68: first defined here
> ---------------------------<snip>---------------------------
>
> Q1)  Sure enough there are two identical copies of this (trivial) debugging
> dump function.  I commented out the copy in graphite.c and got past the
> problem, but this makes me wonder if there's some version skew between cloog
> and gcc?
>
>  After that, there follows about 26000 lines of 'undefined reference to'
> linker error messages.  These fall into two groups, missing _gmpz_* functions
> and missing libstdc++ functions.
>
>  The missing gmpz functions are a consequence of static linking.  The
> definition of BACKENDLIBS appers to be in the wrong order: from gcc/Makefile.in,
>
> ---------------------------<snip>---------------------------
> BACKENDLIBS = $(GMPLIBS) $(CLOOGLIBS) $(PPLLIBS)
> ---------------------------<snip>---------------------------
>
> Q2)  Since CLOOG and PPL call GMP functions, GMPLIBS should be at the end,
> shouldn't it?
>
>  This doesn't cause any problem on platforms where CLOOG and PPL are
> dynamically linked, it just leaves some unresolved references to be filled in
> at runtime by ld.so, but when statically linking it fails.
>
>  The third part of this problem has me really scratching my head.  There are
> undefined references to operators new and delete, cxa_begin/end_catch, even
> iostream stuff.
>
> Q3)  Why is there C++ in my libppl?  Have I done something wrong to get it
> there in the first place, or is it supposed to work somehow?
>
>  At the end of stage 1, I can work around the problem by manually running
> the final link command, but using the (native compiler's) g++ driver instead
> of the plain gcc driver, or by manually adding -lstdc++.  But I can't do
> anything like that to get past the link failure at the end of stage 2; we're
> not using the native compiler any more but the stage 1 compiler and so we've
> only got a crude xgcc that doesn't understand "-x c++", and of course target
> libstdc++ hasn't been built yet.  Something's really wrong here - I can't
> understand why there's C++ involved or how it could work.  Maybe the default
> configure options of PPL have changed to include some C++ interface that
> wasn't built by default at the time the wiki page was written?
>
>  Anyway, TIA for any enlightenment anyone can provide.  I could file PRs or
> patches for the first two bugs if desired,

I would highly appreciate this.

> but the third part has me totally confused, I don't know what to do
> with it.

I'm forwarding this third question to the PPL folks, hoping that they
already dealt with similar cases and probably already have a solution.

Thanks,
Sebastian Pop
--
AMD - GNU Tools