[Bug bootstrap/39316] New: [lto] revision 144454 - Configure should check for elf support (similar to gmp/mpfr/PPL/CLooG)

[Bug bootstrap/39316] New: [lto] revision 144454 - Configure should check for elf support (similar to gmp/mpfr/PPL/CLooG)

[rob1weld at aol dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4409 bytes --]

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)


-- 
           Summary: [lto] revision 144454 - Configure should check for elf
                    support (similar to gmp/mpfr/PPL/CLooG)
           Product: gcc
           Version: lto
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rob1weld at aol dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39316

[Bug bootstrap/39316] [lto] revision 144454 - Configure should check for elf support (similar to gmp/mpfr/PPL/CLooG)

[rob1weld at aol dot com]

------- Comment #1 from rob1weld at aol dot com  2009-02-26 23:44 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39316

[Bug bootstrap/39316] [lto] revision 144454 - Configure should check for elf support (similar to gmp/mpfr/PPL/CLooG)

[bje at gcc dot gnu dot org]

-- 

bje at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |bje at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-07-08 06:18:03
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39316

[Bug bootstrap/39316] [lto] revision 144454 - Configure should check for elf support (similar to gmp/mpfr/PPL/CLooG)

[bje at gcc dot gnu dot org]

------- Comment #2 from bje at gcc dot gnu dot org  2009-07-15 00:51 -------
*** Bug 39097 has been marked as a duplicate of this bug. ***


-- 

bje at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zadeck at naturalbridge dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39316

[Bug bootstrap/39316] [lto] revision 144454 - Configure should check for elf support (similar to gmp/mpfr/PPL/CLooG)

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2009-10-03 22:08 -------
I'm not 100% sure (I don't really understand this bug), but it should be fixed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
           Keywords|                            |lto
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39316

[Bug bootstrap/39316] [lto] revision 144454 - Configure should check for elf support (similar to gmp/mpfr/PPL/CLooG)

[zadeck at naturalbridge dot com]

------- Comment #4 from zadeck at naturalbridge dot com  2009-10-03 23:57 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39316

[Bug bootstrap/39316] [lto] revision 144454 - Configure should check for elf support (similar to gmp/mpfr/PPL/CLooG)

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2009-10-04 09:14 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39316

[Bug bootstrap/39316] [lto] revision 144454 - Configure should check for elf support (similar to gmp/mpfr/PPL/CLooG)

[rob1weld at aol dot com]

------- Comment #6 from rob1weld at aol dot com  2009-10-04 10:25 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39316

[Bug bootstrap/39316] [lto] revision 144454 - Configure should check for elf support (similar to gmp/mpfr/PPL/CLooG)

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2009-10-04 10:32 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39316