It is my Request for Enhancement that the 'Configury' detect if there is enough elf support to build gcc - in a similar manner that gmp, mpfr, PPL and CLooG are tested for. The configury is waiting until it gets past configuring the gcc directory, and even detecting that gelf.h is not present, before the build fails. This Operating System (Debian GNU/Linux) does have "/usr/include/elf.h" in a default installation but is 'lacking enough elf' to build without failing. This should be checked in ../lto_trunk/configure . # make ... Configuring stage 1 in ./gcc configure: creating cache ./config.cache checking build system type... x86_64-unknown-linux-gnu ... checking for pthread.h... yes checking for libelf.h... no checking for libelf/libelf.h... no checking for gelf.h... no checking for libelf/gelf.h... no checking for CHAR_BIT... yes ... make[3]: Entering directory `/usr/src/lto_build/lto-plugin' if /bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"LTO\ plugin\ for\ ld\" -DPACKAGE_TARNAME=\"lto-plugin\" -DPACKAGE_VERSION=\"0.1\" -DPACKAGE_STRING=\"LTO\ plugin\ for\ ld\ 0.1\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"lto-plugin\" -DVERSION=\"0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -I../../lto_trunk/lto-plugin -I../../lto_trunk/lto-plugin/../include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -Werror -g -fkeep-inline-functions -MT lto-plugin.lo -MD -MP -MF ".deps/lto-plugin.Tpo" -c -o lto-plugin.lo ../../lto_trunk/lto-plugin/lto-plugin.c; \ then mv -f ".deps/lto-plugin.Tpo" ".deps/lto-plugin.Plo"; else rm -f ".deps/lto-plugin.Tpo"; exit 1; fi libtool: compile: gcc "-DPACKAGE_NAME=\"LTO plugin for ld\"" -DPACKAGE_TARNAME=\"lto-plugin\" -DPACKAGE_VERSION=\"0.1\" "-DPACKAGE_STRING=\"LTO plugin for ld 0.1\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"lto-plugin\" -DVERSION=\"0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -I../../lto_trunk/lto-plugin -I../../lto_trunk/lto-plugin/../include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -Werror -g -fkeep-inline-functions -MT lto-plugin.lo -MD -MP -MF .deps/lto-plugin.Tpo -c ../../lto_trunk/lto-plugin/lto-plugin.c -fPIC -DPIC -o .libs/lto-plugin.o ../../lto_trunk/lto-plugin/lto-plugin.c:56:4: error: #error "gelf.h not available" ../../lto_trunk/lto-plugin/lto-plugin.c:170: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token ... ../../lto_trunk/lto-plugin/lto-plugin.c:619: error: ‘EV_NONE’ undeclared (first use in this function) make[3]: *** [lto-plugin.lo] Error 1 make[3]: Leaving directory `/usr/src/lto_build/lto-plugin' make[2]: *** [all-stage1-lto-plugin] Error 2 make[2]: Leaving directory `/usr/src/lto_build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/usr/src/lto_build' make: *** [all] Error 2 # ls -l /usr/include/elf.h -rw-r--r-- 1 root root 110896 2009-01-04 10:10 /usr/include/elf.h # ls -l /usr/include/gelf.h ls: cannot access /usr/include/gelf.h: No such file or directory # locate gelf.h (Nothing printed) # locate elf.h /usr/include/elf.h /usr/include/linux/elf.h /usr/include/sys/elf.h # gcc/xgcc -v Using built-in specs. COLLECT_GCC=gcc/xgcc Target: x86_64-unknown-linux-gnu Configured with: ../lto_trunk/configure --prefix=/usr/local/lto --enable-languages=lto,c++ --enable-stage1-checking=all --enable-checking=release Thread model: posix gcc version 4.4.0 20090218 (experimental) [lto revision 144454] (lto merged with rev 144262)
This Bug Report is about the failure to detect that the proper headers and libraries are present _before_ building can be attempted. Even after the extra effort to install libelf (to ensure that the scripts would work) still results in the same error message: # locate gelf.h /usr/local/include/gelf.h /usr/local/include/libelf/gelf.h /usr/src/libelf-0.8.10/lib/gelf.h but there is already a report made for _after_ installing libelf: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39019 Rob
*** Bug 39097 has been marked as a duplicate of this bug. ***
I'm not 100% sure (I don't really understand this bug), but it should be fixed.
Richard, the problem is that at least for the linux world there are two elf implementations that while they claim to be compatible are distinctly different on the inside. LTO, for better or worse, needs to use features that are not necessarily part of the "standard" elf, for some definition of standard. unlike gmp and mpfr, where there has always been 1 open source version, elf was reverse engineered for linux from the sun version at least twice, each with its own warts. It has not helped anything that suse and redhat seem to have chosen to distribute different implementations. this led to a fair amount of confusion when mark mitchell and i started working on lto because codesourcery generally runs redhat and naturalbridge runs suse. We were always breaking the code on the others machines. i think that iant "solved" this problem for gold by just writing his own elf library rather than relying on what was installed which is what lto does. Aside from going down that road, we are most likely screwed because lto needs stuff out of the mainstream elf. I hope that this clarifies some of your issues here. kenny
I see. This particular issue should be fixed as libelf and the clone from elfutils use different SONAMEs and the configure test in GCC checks for the actual features it uses with a link test. The only thing that may happen is that with broken installations (headers from one lib, shared library from the other) things will break and we'd need to run a test program to detect this weird case.
(In reply to comment #5) > I see. This particular issue should be fixed as libelf and the clone from > elfutils use different SONAMEs and the configure test in GCC checks for the > actual features it uses with a link test. The only thing that may happen > is that with broken installations (headers from one lib, shared library from > the other) things will break and we'd need to run a test program to detect > this weird case. >> It is my Request for Enhancement that the 'Configury' detect if >> there is enough elf support to build gcc - in a similar manner that >> gmp, mpfr, PPL and CLooG are tested for. ... I suggest that gmp, mpfr, PPL, CLooG and "LTOable ELF" all use "similar" configury to check that each will work correctly with GCC _WHEN_ we later get to the portion of the build that actually uses the feature. The "similar configury" can each call a different snippet of code (obviously) to test that _whatever_ the configure script thinks it has detected will actually compile a program that will execute and produce an expected result. Program code that can only be compiled (without warnings or errors) but are not executable should be maked as compilable but not executable (for cross compiling). _IF_ we can not get whatever we thought we detected to compile we need to signal this in the _FIRST_ configure script and _not_ leave it to be discovered by some configure script that get ran 3/4 though the build days later, that is annoying and happens too frequently. Richard, if you are closing this can you post the Changelog for this BR. Thanks, Rob
2009-09-14 Diego Novillo <dnovillo@google.com> * configure.ac: Add link test to check for some of the libelf functions used. Tidy some formatting. * configure: Regenerate.