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