| Summary: | cloog link failure with non-gcc bootstrap compiler | ||
|---|---|---|---|
| Product: | gcc | Reporter: | David Binderman <dcb314> |
| Component: | bootstrap | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gcc-bugs |
| Priority: | P3 | ||
| Version: | 4.4.0 | ||
| Target Milestone: | --- | ||
| Host: | x86_64-suse-linux | Target: | |
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | ||
Subject: Re: New: cloog link failure with non-gcc bootstrap compiler On Sat, Mar 7, 2009 at 02:28, dcb314 at hotmail dot com <gcc-bugzilla@gcc.gnu.org> wrote: > Using -L/lib for -lcloog looks deeply suspicious to me. > Even more so, -L/lib for -lppl_c and -lppl. Sounds like the problem is in the configure scripts. What is the configure command that you are using? Thanks, Sebastian (In reply to comment #1) > Sounds like the problem is in the configure scripts. Righto. > What is the configure command that you are using? CC="icc" ../whatever/configure --prefix=somewhereElse --enable-checking It might be significant that the Intel compiler is 32 bit, but running on a 64 bit box. This should be fixed by now. Please open again this PR if this is still a problem. Sebastian |
I usually bootstrap the weekly snapshot of gcc 4.4 with the Intel C compiler. This usually works, but this week snapshot 20090306 didn't. There seem to be some fun & games with linking together to make cc1-dummy. icc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prot otypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmi ssing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overle ngth-strings -fno-common -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o att ribs.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-obj c-common.o c-dump.o c-pch.o c-parser.o i386-c.o c-gimplify.o tree-mudflap.o c-pr etty-print.o c-omp.o dummy-checksum.o \ main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/ libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/lib decnumber.a -L/lib -lcloog -L/lib -lppl_c -lppl -lgmpxx -lmpfr -lgmp libbackend.a(graphite.o): In function `cloog_finalize': /usr/include/cloog/ppl_backend.h:54: undefined reference to `ppl_finalize' libbackend.a(graphite.o): In function `schedule_to_scattering': /home/dcb/gcc/20090306/working/gcc/../../src/gcc-4.4-20090306/gcc/graphite.c:666 : undefined reference to `cloog_matrix_alloc' libbackend.a(graphite.o): In function `print_graphite_bb': /home/dcb/gcc/20090306/working/gcc/../../src/gcc-4.4-20090306/gcc/graphite.c:708 : undefined reference to `cloog_matrix_print' /home/dcb/gcc/20090306/working/gcc/../../src/gcc-4.4-20090306/gcc/graphite.c:747 : undefined reference to `cloog_matrix_print' /home/dcb/gcc/20090306/working/gcc/../../src/gcc-4.4-20090306/gcc/graphite.c:748 : undefined reference to `cloog_matrix_free' ... Given the number of function with names starting with "cloog", I'd guess that something has gone wrong in the detection of the correct location of the cloog libraries. Using -L/lib for -lcloog looks deeply suspicious to me. Even more so, -L/lib for -lppl_c and -lppl.