public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Problems compiling gcc-4.1-branch on AMD64
@ 2006-05-07 16:06 Asfand Yar Qazi
  2006-05-12 11:45 ` Kai Ruottu
  0 siblings, 1 reply; 4+ messages in thread
From: Asfand Yar Qazi @ 2006-05-07 16:06 UTC (permalink / raw)
  To: gcc-help

Hi,

I do this:

../gcc-4.1-branch/configure --prefix=/usr/local/gcc --disable-nls
--enable-version-specific-runtime-libs --enable-__cxa_atexit
--enable-languages=c,c++

and get this:

creating cache ./config.cache
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking build system type... x86_64-unknown-linux-gnu
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for gnatbind... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2
checking for correct version of gmp.h... yes
checking for MPFR... no
*** This configuration is not supported in the following subdirectories:
     target-libada gnattools target-libgfortran target-libffi target-boehm-gc
target-zlib target-libjava zlib fastjar
 target-libobjc
    (Any other directories should still work fine.)
checking for bison... bison -y
checking for bison... bison
checking for gm4... no
checking for gnum4... no
checking for m4... m4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for expect... no
checking for runtest... no
checking for x86_64-unknown-linux-gnu-ar... no
checking for ar... ar
checking for x86_64-unknown-linux-gnu-as... no
checking for as... as
checking for x86_64-unknown-linux-gnu-dlltool... no
checking for dlltool... no

... and so on

or this:

../gcc-4.1-branch/configure --prefix=/usr/local/gcc --disable-nls
--enable-version-specific-runtime-libs --enable-__cxa_atexit
--enable-languages=c,c++ --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu

and get this:

creating cache ./config.cache
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking build system type... x86_64-pc-linux-gnu
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for gnatbind... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2
checking for correct version of gmp.h... yes
checking for MPFR... no
*** This configuration is not supported in the following subdirectories:
     target-libada gnattools target-libgfortran target-libffi target-boehm-gc
target-zlib target-libjava zlib fastjar target-libobjc
    (Any other directories should still work fine.)
checking for bison... bison -y
checking for bison... bison
checking for gm4... no
checking for gnum4... no
checking for m4... m4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for expect... no
checking for runtest... no
checking for x86_64-pc-linux-gnu-ar... x86_64-pc-linux-gnu-ar
checking for x86_64-pc-linux-gnu-as... x86_64-pc-linux-gnu-as
checking for x86_64-pc-linux-gnu-dlltool... no
checking for dlltool... no
checking for x86_64-pc-linux-gnu-ld...
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../../x86_64-pc-linux-gnu/bin/ld
checking for x86_64-pc-linux-gnu-lipo... no
checking for lipo... no
checking for x86_64-pc-linux-gnu-nm... x86_64-pc-linux-gnu-nm
checking for x86_64-pc-linux-gnu-ranlib... x86_64-pc-linux-gnu-ranlib
checking for x86_64-pc-linux-gnu-strip... x86_64-pc-linux-gnu-strip
checking for x86_64-pc-linux-gnu-windres... no
checking for windres... no
checking for x86_64-pc-linux-gnu-objcopy... x86_64-pc-linux-gnu-objcopy
checking for x86_64-pc-linux-gnu-objdump... x86_64-pc-linux-gnu-objdump
checking for x86_64-pc-linux-gnu-ar... x86_64-pc-linux-gnu-ar
checking for x86_64-pc-linux-gnu-as... x86_64-pc-linux-gnu-as

... and so on, which actually seems to be OK.


But both fail like this (or similarly so):

config.status: creating Makefile
config.status: creating include/Makefile
config.status: creating libmath/Makefile
config.status: creating libsupc++/Makefile
config.status: creating src/Makefile
config.status: creating po/Makefile
config.status: creating testsuite/Makefile
config.status: creating scripts/testsuite_flags
config.status: creating config.h
config.status: executing default-1 commands
Adding multilib support to Makefile in ../../../gcc-4.1-branch/libstdc++-v3
multidirs=32
with_multisubdir=
Running configure in multilib subdirs 32
pwd:
/home/ayqazi/src/packages/gcc-4.1-svn/gcc-4.1-build/x86_64-pc-linux-gnu/libstdc++-v3
Running configure in multilib subdir 32
pwd: /home/ayqazi/src/packages/gcc-4.1-svn/gcc-4.1-build/x86_64-pc-linux-gnu
mkdir 32
configure: creating cache ./config.cache
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for x86_64-pc-linux-gnu-gcc...
/home/ayqazi/src/packages/gcc-4.1-svn/gcc-4.1-build/./gcc/xgcc
-B/home/ayqazi/src/packages/gcc-4.1-svn/gcc-4.1-build/./gcc/
-B/usr/local/gcc/x86_64-pc-linux-gnu/bin/
-B/usr/local/gcc/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/gcc/x86_64-pc-linux-gnu/include -isystem
/usr/local/gcc/x86_64-pc-linux-gnu/sys-include  -m32
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[3]: *** [configure-target-libstdc++-v3] Error 1
make[3]: Leaving directory `/home/ayqazi/src/packages/gcc-4.1-svn/gcc-4.1-build'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/ayqazi/src/packages/gcc-4.1-svn/gcc-4.1-build'
make[1]: *** [profiledbootstrap] Error 2
make[1]: Leaving directory `/home/ayqazi/src/packages/gcc-4.1-svn/gcc-4.1-build'
make: *** [build] Error 2


What's going on?

Thanks

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Problems compiling gcc-4.1-branch on AMD64
  2006-05-07 16:06 Problems compiling gcc-4.1-branch on AMD64 Asfand Yar Qazi
@ 2006-05-12 11:45 ` Kai Ruottu
  2006-05-13  0:10   ` Asfand Yar Qazi
  0 siblings, 1 reply; 4+ messages in thread
From: Kai Ruottu @ 2006-05-12 11:45 UTC (permalink / raw)
  To: Asfand Yar Qazi; +Cc: gcc-help

Asfand Yar Qazi kirjoitti:
> ../gcc-4.1-branch/configure --prefix=/usr/local/gcc --disable-nls
> --enable-version-specific-runtime-libs --enable-__cxa_atexit
> --enable-languages=c,c++ --build=x86_64-pc-linux-gnu
> --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
>
> and get this:
>
> checking host system type... x86_64-pc-linux-gnu
> checking target system type... x86_64-pc-linux-gnu
> checking build system type... x86_64-pc-linux-gnu
> <snip>

> *** This configuration is not supported in the following subdirectories:
>      target-libada gnattools target-libgfortran target-libffi target-boehm-gc
>   
 Funny but I got :

/data1/home/src/gcc-4.1.0/build # ls -l x86_64-suse-linux9.2
total 44
drwxr-xr-x  11 root root 4096 2006-05-12 13:57 ./
drwxr-xr-x  11 root root 4096 2006-05-12 13:19 ../
drwxr-xr-x  10 root root 4096 2006-05-12 13:59 32/
drwxr-xr-x   4 root root 4096 2006-05-12 14:06 boehm-gc/
drwxr-xr-x   6 root root 4096 2006-05-12 13:56 libffi/
drwxr-xr-x   4 root root 4096 2006-05-12 13:26 libiberty/
drwxr-xr-x  11 root root 4096 2006-05-12 14:03 libjava/
drwxr-xr-x   6 root root 4096 2006-05-12 13:51 libmudflap/
drwxr-xr-x   5 root root 4096 2006-05-12 13:54 libssp/
drwxr-xr-x   9 root root 4096 2006-05-12 13:22 libstdc++-v3/
drwxr-xr-x   3 root root 4096 2006-05-12 14:04 zlib/

when I tried gcc-4.1.0 for the SuSE 9.2/x86_64 target....  The
'target-libffi' and 'target-boehm-gc' seemed to be "supported" here !
Maybe leaving 'java' out from the '--enable-languages=' caused this.

But not completely for cross-building :-(, the build stopped with :

/opt/gcc/x86_64-suse-linux9.2/bin/ld: cannot find /lib64/libpthread.so.0
collect2: ld returned 1 exit status
make[3]: *** [libgcjgc.la] Error 1
make[3]: Leaving directory 
`/data1/home/src/gcc-4.1.0/build/x86_64-suse-linux9.2/boehm-gc'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory 
`/data1/home/src/gcc-4.1.0/build/x86_64-suse-linux9.2/boehm-gc'
make[1]: *** [all-target-boehm-gc] Error 2
make[1]: Leaving directory `/data1/home/src/gcc-4.1.0/build'

Which simply told that not only the '/usr/lib*/libc.so's, but also the
'/usr/lib*/libpthread.so' scripts were 'one eyed'ly written for only native
use...  There of course then was no symlinks for the 'libpthread.so.0's from
'usr/lib*' to '../../lib*' for finding those 'bare libpthread.so.0's 
after editing
these scripts. But adding them helped....

> checking whether the C compiler works... configure: error: cannot run C
> compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details.
>   

> What's going on?
>   
 You didn't find your eyeglasses and therefore didn't see the "See... 
for more
details" suggestion ?  "Who else could raise the cat's tail if not the 
cat itself".
Whatever went wrong, can be seen in that 'config.log' in the directory where
the configure failed !

 Your "gcc-4.1-branch" as the name for the 'gcc-4.1.x' sources of course 
sounds
odd.  If these sources were experimental prereleases for something, they can
be very badly broken sometimes. I would suggest trying the official releases
first..

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Problems compiling gcc-4.1-branch on AMD64
  2006-05-12 11:45 ` Kai Ruottu
@ 2006-05-13  0:10   ` Asfand Yar Qazi
  2006-05-14 18:23     ` Kai Ruottu
  0 siblings, 1 reply; 4+ messages in thread
From: Asfand Yar Qazi @ 2006-05-13  0:10 UTC (permalink / raw)
  To: gcc-help

Kai Ruottu wrote:
> Asfand Yar Qazi kirjoitti:
> 
>> What's going on?
>>   
> You didn't find your eyeglasses and therefore didn't see the "See... for
> more
> details" suggestion ?  "Who else could raise the cat's tail if not the
> cat itself".
> Whatever went wrong, can be seen in that 'config.log' in the directory
> where
> the configure failed !

There's nothing of benefit in config.log, especially since I can't find the
one this particular command refers to.

> 
> Your "gcc-4.1-branch" as the name for the 'gcc-4.1.x' sources of course
> sounds
> odd.  If these sources were experimental prereleases for something, they
> can
> be very badly broken sometimes. I would suggest trying the official
> releases
> first..
> 
> 

gcc-4.1-branch is where all the bug-fixes occur for the 4.1 release.  It is
theoretically more stable than the latest gcc 4.1 official release.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Problems compiling gcc-4.1-branch on AMD64
  2006-05-13  0:10   ` Asfand Yar Qazi
@ 2006-05-14 18:23     ` Kai Ruottu
  0 siblings, 0 replies; 4+ messages in thread
From: Kai Ruottu @ 2006-05-14 18:23 UTC (permalink / raw)
  To: Asfand Yar Qazi; +Cc: gcc-help

Asfand Yar Qazi kirjoitti:
> Kai Ruottu wrote:
>   
>> Whatever went wrong, can be seen in that 'config.log' in the directory
>> where the configure failed !
 > There's nothing of benefit in config.log, especially since I can't 
find the one this
 > particular command refers to.

  So running a 32-bit application during the libstdc++-v3 configure 
somehow didn't
succeed. This is the clue...  Maybe it is hard to find what failed 
there, which shouldn't
fail, but nobody else than you can do that...

 I can only ask stupid questions like: "Does the new GCC work when 
trying something
very simple?  Doing the following:

1. build only GCC : 'make all-gcc'
2. install only GCC: 'make install-gcc'
3. try compiling and linking a 32-bit "Hello World"
4. ask about the error got with it here if this simple "sanity test" failed

could lead to some progress in this....  But I cannot believe you didn't 
do this before
asking anything.  If the new GCC doesn't work with "Hello World", it is 
quite sure
that those simple compile & link tests in the libstdc++-v3 configure 
would fail too.
It is insane to even try to build libiberty, libstdc++ etc. if the new 
compiler with the
binutils and the target C library cannot even produce a Hello World...  
It is expected
being capable to do that, so the extra target libraries are tried to be 
produced.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-05-14 18:23 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-05-07 16:06 Problems compiling gcc-4.1-branch on AMD64 Asfand Yar Qazi
2006-05-12 11:45 ` Kai Ruottu
2006-05-13  0:10   ` Asfand Yar Qazi
2006-05-14 18:23     ` Kai Ruottu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).