Re: [PPL-devel] Graphite/Cloog/PPL problems on Cygwin, HEAD broken maybe?
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
Sebastian Pop wrote:
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.
Hi there,
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? All the best,
Roberto
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.
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
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
Dave Korn wrote:
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.
$ find . -name cc1 ./prev-gcc/cc1 ./gcc/cc1 ./stage1-gcc/cc1 $ find . -name cc1 | xargs ldd ./prev-gcc/cc1: linux-vdso.so.1 => (0x00007fffb37ff000) libmpfr.so.1 => /usr/lib64/libmpfr.so.1 (0x0000003e34000000) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x0000003e3b400000) libppl_c.so.2 => /usr/local/lib64/libppl_c.so.2 (0x0000000002027000) libppl.so.7 => /usr/local/lib64/libppl.so.7 (0x0000000000110000) libgmpxx.so.4 => /usr/lib64/libgmpxx.so.4 (0x00000000015e7000) libc.so.6 => /lib64/libc.so.6 (0x0000003e33c00000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003e3de00000) libm.so.6 => /lib64/libm.so.6 (0x000000000278a000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000000001880000) /lib64/ld-linux-x86-64.so.2 (0x0000003e33800000) ./gcc/cc1: linux-vdso.so.1 => (0x00007fff4e3fe000) libmpfr.so.1 => /usr/lib64/libmpfr.so.1 (0x0000003e34000000) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x0000003e3b400000) libppl_c.so.2 => /usr/local/lib64/libppl_c.so.2 (0x0000000002fbc000) libppl.so.7 => /usr/local/lib64/libppl.so.7 (0x0000000000110000) libgmpxx.so.4 => /usr/lib64/libgmpxx.so.4 (0x00000000064f1000) libc.so.6 => /lib64/libc.so.6 (0x0000003e33c00000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003e3de00000) libm.so.6 => /lib64/libm.so.6 (0x0000000006d01000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000000110b000) /lib64/ld-linux-x86-64.so.2 (0x0000003e33800000) ./stage1-gcc/cc1: linux-vdso.so.1 => (0x00007fff7bdff000) libmpfr.so.1 => /usr/lib64/libmpfr.so.1 (0x0000003e34000000) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x0000003e3b400000) libppl_c.so.2 => /usr/local/lib64/libppl_c.so.2 (0x00007f9f736e1000) libppl.so.7 => /usr/local/lib64/libppl.so.7 (0x0000000000110000) libgmpxx.so.4 => /usr/lib64/libgmpxx.so.4 (0x00007f9f734dc000) libc.so.6 => /lib64/libc.so.6 (0x0000003e33c00000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003e3de00000) libm.so.6 => /lib64/libm.so.6 (0x00007f9f73256000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f9f7303f000) /lib64/ld-linux-x86-64.so.2 (0x0000003e33800000)
This is from HEAD of 20 minutes ago. Notice that I had to work around the multiple definition of debug_value() you already reported. All the best,
Roberto
Sebastian Pop wrote:
Hi Seb,
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.
Righto, will get cracking.
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.
I see Roberto downthread, will reply.
cheers, DaveK
Dave Korn wrote:
Sebastian Pop wrote:
Hi Seb,
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.
Righto, will get cracking.
You already posted a patch for the first one and got approval from RG. Since my one requires approval from a build-system maintainer, I've created
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38862
(and will repost my patch which I think went unnoticed on the tail-end of your thread). I'll file another one for the C++ library problem later.
cheers, DaveK
participants (5)
-
Dave Korn -
David Edelsohn -
Joseph S. Myers -
Roberto Bagnara -
Sebastian Pop