Hello Dave, Thanks for testing Graphite on i686-pc-cygwin.
On Mon, Jan 12, 2009 at 9:52 AM, Dave Korn <dave.korn.cyg...@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