Bug 35577 - configure: error: cannot compute suffix of object files
Summary: configure: error: cannot compute suffix of object files
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 36248 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-03-13 20:43 UTC by Al Danial
Modified: 2008-05-16 19:00 UTC (History)
2 users (show)

See Also:
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments
config.log (5.79 KB, text/plain)
2008-03-13 20:50 UTC, Al Danial
Details
x86_64-unknown-linux-gnu/libgcc/config.log (2.55 KB, text/plain)
2008-03-13 23:10 UTC, Al Danial
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Al Danial 2008-03-13 20:43:10 UTC
This is on an AMD Opteron system running the 64 bit version of RHEL 4.3 (curious  that it is identified as "unknown-linux-gnu").  I'm building 4.3.0 with GCC 3.4.5 20051201 (Red Hat 3.4.5-2).

My configure command is
  ../gcc-4.3.0/configure --with-gmp=/apps/gmp/4.2.2 --with-mpfr=/apps/mpfr/2.3.0 --prefix=/apps/gcc/4.2.2 --enable-languages=c,c++,fortran,java,objc,obj-c++,treelang

The configure completes successfully.  The error is triggered by
  make bootstrap

The last 20 or so lines of output from make boostrap are:

if [ xinfo = xinfo ]; then \
        makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000 --no-split -I ../../gcc-4.3.0/gcc/doc \
                -I ../../gcc-4.3.0/gcc/doc/include -o doc/gccinstall.info ../../gcc-4.3.0/gcc/doc/install.texi; \
fi
if [ xinfo = xinfo ]; then \
        makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000 --no-split -I . -I ../../gcc-4.3.0/gcc/doc \
                -I ../../gcc-4.3.0/gcc/doc/include -o doc/cppinternals.info ../../gcc-4.3.0/gcc/doc/cppinternals.texi; \
fi
make[3]: Leaving directory `/scratch/gcc_exe/gcc'
mkdir -p -- x86_64-unknown-linux-gnu/libgcc
Checking multilib configuration for libgcc...
Configuring stage 1 in x86_64-unknown-linux-gnu/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for x86_64-unknown-linux-gnu-ar... ar
checking for x86_64-unknown-linux-gnu-lipo... lipo
checking for x86_64-unknown-linux-gnu-nm... /scratch/gcc_exe/./gcc/nm
checking for x86_64-unknown-linux-gnu-ranlib... ranlib
checking for x86_64-unknown-linux-gnu-strip... strip
checking whether ln -s works... yes
checking for x86_64-unknown-linux-gnu-gcc... /scratch/gcc_exe/./gcc/xgcc -B/scratch/gcc_exe/./gcc/ -B/apps/gcc/4.2.2/x86_64-unknown-linux-gnu/bin/ -B/apps/gcc/4.2.2/x86_64-unknown-linux-gnu/lib/ -isystem /apps/gcc/4.2.2/x86_64-unknown-linux-gnu/include -isystem /apps/gcc/4.2.2/x86_64-unknown-linux-gnu/sys-include
checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage1-target-libgcc] Error 1
make[2]: Leaving directory `/scratch/gcc_exe'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/scratch/gcc_exe'
make: *** [bootstrap] Error 2


For what it's worth, the identical problem happens on a 64 bit Solaris 9 system.
Comment 1 Al Danial 2008-03-13 20:50:16 UTC
Created attachment 15310 [details]
config.log
Comment 2 Andrew Pinski 2008-03-13 21:27:50 UTC
You attached the wrong config.log.  We need the one in the x86_64-unknown-linux-gnu/libgcc subdirectory where configure is failing.
Comment 3 Al Danial 2008-03-13 23:10:06 UTC
Created attachment 15312 [details]
x86_64-unknown-linux-gnu/libgcc/config.log

The error in x86_64-unknown-linux-gnu/libgcc/config.log suggests it has trouble loading libmpfr.so.1.  However the MPFR libraries exist under the "--with-mpfr=" directory I gave to the configure script:

> ll /apps/mpfr/2.3.0/lib/
total 3420
drwxr-sr-x  2 s116493 mis    4096 Nov 26 13:44 ./
drwxr-sr-x  5 s116493 mis    4096 Nov 26 13:44 ../
-rw-r--r--  1 s116493 mis 2409846 Nov 26 13:44 libmpfr.a
-rwxr-xr-x  1 s116493 mis     866 Nov 26 13:44 libmpfr.la*
lrwxrwxrwx  1 s116493 mis      16 Nov 26 13:44 libmpfr.so -> libmpfr.so.1.1.0*
lrwxrwxrwx  1 s116493 mis      16 Nov 26 13:44 libmpfr.so.1 -> libmpfr.so.1.1.0*
-rwxr-xr-x  1 s116493 mis 1062796 Nov 26 13:44 libmpfr.so.1.1.0*
Comment 4 brian 2008-03-14 03:05:39 UTC
Subject: Re:  configure: error: cannot compute suffix of 
 object files

al dot danial at gmail dot com wrote:

> The error in x86_64-unknown-linux-gnu/libgcc/config.log suggests it has trouble
> loading libmpfr.so.1.  However the MPFR libraries exist under the
> "--with-mpfr=" directory I gave to the configure script:

The fact that they exist there doesn't mean the dynamic loader can find
them unless you tell it.  Have you set LD_LIBRARY_PATH?  Or edited
ld.conf?
Comment 5 Al Danial 2008-03-14 21:15:39 UTC
Indeed, adding the MPFR and GPM lib directories to LD_LIBRARY_PATH solves the problem.  For some reason I thought configure would handle this for me since I gave it --with-gmp and --with-mpfr settings.  Would have been nice if configure tested for this and given a helpful error.  In any event I'll close this out as an invalid bug report.
Comment 6 brian 2008-03-15 10:20:19 UTC
Subject: Re:  configure: error: cannot compute suffix of 
 object files

al dot danial at gmail dot com wrote:

> Indeed, adding the MPFR and GPM lib directories to LD_LIBRARY_PATH solves the
> problem.  For some reason I thought configure would handle this for me since I

It's the same case when installing any shared library on the system --
you have to inform the dynamic linker of their location (or put them
somewhere it already knows to search) otherwise programs that use that
library can't run.  Configure doesn't really know how you want to handle
this: adding a path to LD_LIBRARY_PATH is but one way; you could also
add the path to ld.so.conf, or relink the libraries with the path
hardcoded (RPATH).  It wouldn't be very prudent to have configure assume
that it should be adding things to LD_LIBRARY_PATH.

The reason the configure checks succeeded is they are checking for
compile time and link time behavior, i.e. they are exercising the link
editor (ld) not the dynamic linker (ld.so).  I suppose it would be
possible for configure to try an additional execute check for sanity if
it's not crosscompiling.  But the best you could do there is report a
problem, as again fixing it is outside of the realm of configure.
Comment 7 Vladimir Kondratyev 2008-05-16 19:00:59 UTC
*** Bug 36248 has been marked as a duplicate of this bug. ***