GCC configure problem with 32-bit stuff on x86_64

GCC configure problem with 32-bit stuff on x86_64

[Chris Lu]

Hi all,

I am trying to build gcc 4.0.2 on a x86_64 system with 32-bit support.
Apparently it will not configure libstdc++ for a 32-bit build properly
(generates Makefile with no 'all' target) and the error from running
config.status manually is:

checking for sin in -lm... configure: error: Link tests are not
allowed after GCC_NO_EXECUTABLES.

If anyone can help me with this, I would appreciate it greatly. Thanks.

Chris Lu

Re: GCC configure problem with 32-bit stuff on x86_64

[Kai Ruottu]

Chris Lu wrote:

> I am trying to build gcc 4.0.2 on a x86_64 system with 32-bit support.
> Apparently it will not configure libstdc++ for a 32-bit build properly
> (generates Makefile with no 'all' target) and the error from running
> config.status manually is:
> 
> checking for sin in -lm... configure: error: Link tests are not
> allowed after GCC_NO_EXECUTABLES.

You didn't tell your "x86_64 system" type but let's guess it being
Linux, not FreeBSD, NetBSD or something else...

Just (pre)install the 32-bit C libraries, they should be in '/lib'
and '/usr/lib' in the Linux case. The default 64-bit libs then are
normally in '/lib64' and '/usr/lib64'.

And you can always preinstall only the 'gcc' components from the
'$build/gcc' directory via 'make install-gcc' and then try compiling
and linking a "Hello World" using '-m32', to see if creating 32-bit
executables will succeed. If not, try to fix the problem before going
to configure libiberty and libstdc++... If you cannot invent the fix,
just tell what errors you will get during the "Hello World" linking
and let people to guess the problem. Using the '-Wl,-verbose' in the
GCC command line, giving '-verbose' to the GNU linker, could also help
a lot...

Re: GCC configure problem with 32-bit stuff on x86_64

[Chris Lu]

On 11/14/05, Kai Ruottu <karuottu@mbnet.fi> wrote:
> You didn't tell your "x86_64 system" type but let's guess it being
> Linux, not FreeBSD, NetBSD or something else...
>

You guessed correctly, it is a Linux system. Sorry about that...

> Just (pre)install the 32-bit C libraries, they should be in '/lib'
> and '/usr/lib' in the Linux case. The default 64-bit libs then are
> normally in '/lib64' and '/usr/lib64'.

For some reason I have */lib for the 64-bit libs, */lib32 for 32-bit,
and */lib64 symlinked to */lib.

> And you can always preinstall only the 'gcc' components from the
> '$build/gcc' directory via 'make install-gcc' and then try compiling
> and linking a "Hello World" using '-m32', to see if creating 32-bit
> executables will succeed. If not, try to fix the problem before going
> to configure libiberty and libstdc++... If you cannot invent the fix,
> just tell what errors you will get during the "Hello World" linking
> and let people to guess the problem. Using the '-Wl,-verbose' in the
> GCC command line, giving '-verbose' to the GNU linker, could also help
> a lot...

I tried exactly that, after building as much as I could. The command
and output are:


$ x86_64-unknown-linux-gnu-gcc-4.0.2 -o hello -m32 -L/lib32/ -v hello.c
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.0.2/configure
Thread model: posix
gcc version 4.0.2
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.0.2/cc1 -quiet -v
hello.c -quiet -dumpbase hello.c -m32 -mtune=k8 -auxbase hello
-version -o /tmp/cc9cB9N0.s
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/include
 /usr/include
End of search list.
GNU C version 4.0.2 (x86_64-unknown-linux-gnu)
        compiled by GNU C version 3.3.5 (Debian 1:3.3.5-8ubuntu2).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128234
 as -V -Qy --32 -o /tmp/cc03Pm1W.o /tmp/cc9cB9N0.s
GNU assembler version 2.15 (x86_64-linux) using BFD version 2.15
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.0.2/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o hello
/usr/lib/../lib/crt1.o /usr/lib/../lib/crti.o
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/32/crtbegin.o
-L/lib32/ -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/32
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/../../../../lib
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/../../..
-L/lib/../lib -L/usr/lib/../lib /tmp/cc03Pm1W.o -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/32/crtend.o
/usr/lib/../lib/crtn.o
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`/usr/lib/../lib/crt1.o' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`/usr/lib/../lib/crti.o' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`/usr/lib/../lib/crtn.o' is incompatible with i386 output
/usr/lib/../lib/crt1.o(.text+0x13): In function `_start':
../sysdeps/x86_64/elf/start.S:89: undefined reference to `__libc_csu_fini'
/usr/lib/../lib/crt1.o(.text+0x1a):../sysdeps/x86_64/elf/start.S:90:
undefined reference to `__libc_csu_init'
collect2: ld returned 1 exit status

Any help would be appreciated.

Chris Lu

Re: GCC configure problem with 32-bit stuff on x86_64

[Kai Ruottu]

Chris Lu wrote:
> On 11/14/05, Kai Ruottu <karuottu@mbnet.fi> wrote:
> 
>>You didn't tell your "x86_64 system" type but let's guess it being
>>Linux, not FreeBSD, NetBSD or something else...
> 
> You guessed correctly, it is a Linux system. Sorry about that...
> 
>>Just (pre)install the 32-bit C libraries, they should be in '/lib'
>>and '/usr/lib' in the Linux case. The default 64-bit libs then are
>>normally in '/lib64' and '/usr/lib64'.
> 
> For some reason I have */lib for the 64-bit libs, */lib32 for 32-bit,
> and */lib64 symlinked to */lib.

  The FSF GCC sources seem to expect the Linux/x86_64 installations
to have the default 64-bit stuff in '*/lib64' and the 32-bit stuff
in '*/lib', so you have a problem to solve with this. What kind of
Linux/x86_64 puts its libraries this way?

  Anyway the place where the default settings for GCC are told, is
the 'gcc/config/i386/t-linux64', a clip from its beginning :

----------------------- clip ------------------------------------
# On x86-64 we do not need any exports for glibc for 64-bit libgcc_s,
# override the settings
# from t-slibgcc-elf-ver and t-linux
SHLIB_MAPFILES = $(srcdir)/libgcc-std.ver \
		 $(srcdir)/config/i386/libgcc-x86_64-glibc.ver

MULTILIB_OPTIONS = m64/m32
MULTILIB_DIRNAMES = 64 32
MULTILIB_OSDIRNAMES = ../lib64 ../lib
----------------------- clip ------------------------------------

  So changing the last row to be:

MULTILIB_OSDIRNAMES = ../lib ../lib32

should change the default behaviour to be for your 'custom'
Linux/x86_64... At least I think this being the place for setting
those 'operating system directory names'.

> $ x86_64-unknown-linux-gnu-gcc-4.0.2 -o hello -m32 -L/lib32/ -v hello.c
<snip>
>  /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.0.2/collect2
> --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o hello
> /usr/lib/../lib/crt1.o /usr/lib/../lib/crti.o
> /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/32/crtbegin.o
> -L/lib32/ -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/32
> -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2
> -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/../../../../lib
> -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/../../..
> -L/lib/../lib -L/usr/lib/../lib /tmp/cc03Pm1W.o -lgcc --as-needed
> -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
> /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/32/crtend.o
> /usr/lib/../lib/crtn.o

Yes, with the '-m32' the '*/lib' stuff is tried to be used... Without
it you should get the '*/lib64' in those '-L' options with your current
settings. And changing what I suggested, restarting the build (it should
see the target-makefile-fragment changed and rebuild what this change
requires), the '*/lib' stuff should be searched as default and '*/lib32'
stuff with the '-m32'...

Re: GCC configure problem with 32-bit stuff on x86_64

[Chris Lu]

Hi,

On 11/15/05, Kai Ruottu <karuottu@mbnet.fi> wrote:
>
>   The FSF GCC sources seem to expect the Linux/x86_64 installations
> to have the default 64-bit stuff in '*/lib64' and the 32-bit stuff
> in '*/lib', so you have a problem to solve with this. What kind of
> Linux/x86_64 puts its libraries this way?

I believe Debian and Debian-based distros do (I'm using Ubuntu).

>   Anyway the place where the default settings for GCC are told, is
> the 'gcc/config/i386/t-linux64', a clip from its beginning :
>
> ----------------------- clip ------------------------------------
> # On x86-64 we do not need any exports for glibc for 64-bit libgcc_s,
> # override the settings
> # from t-slibgcc-elf-ver and t-linux
> SHLIB_MAPFILES = $(srcdir)/libgcc-std.ver \
>                  $(srcdir)/config/i386/libgcc-x86_64-glibc.ver
>
> MULTILIB_OPTIONS = m64/m32
> MULTILIB_DIRNAMES = 64 32
> MULTILIB_OSDIRNAMES = ../lib64 ../lib
> ----------------------- clip ------------------------------------
>
>   So changing the last row to be:
>
> MULTILIB_OSDIRNAMES = ../lib ../lib32
>
> should change the default behaviour to be for your 'custom'
> Linux/x86_64... At least I think this being the place for setting
> those 'operating system directory names'.
>

I did that, and gcc fails on:

checking for g++ that supports -ffunction-sections -fdata-sections... yes
checking for sin in -lm... configure: error: Link tests are not
allowed after GCC_NO_EXECUTABLES.
make: *** [configure-target-libstdc++-v3] Error 1

as before. I tried the make install-gcc trick to bypass libstdc++, and
that installs properly but it still has problems with crt*.o:

$ gcc -o hello -m32 -v hello.c
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.0.2/configure
Thread model: posix
gcc version 4.0.2
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.0.2/cc1 -quiet -v
hello.c -quiet -dumpbase hello.c -m32 -mtune=k8 -auxbase hello
-version -o /tmp/ccWDV8FJ.s
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/include
 /usr/include
End of search list.
GNU C version 4.0.2 (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.0.2.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128234
 as -V -Qy --32 -o /tmp/ccqG9m2o.o /tmp/ccWDV8FJ.s
GNU assembler version 2.15 (x86_64-linux) using BFD version 2.15
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.0.2/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o hello
/usr/lib/../lib32/crt1.o /usr/lib/../lib32/crti.o
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/32/crtbegin.o
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/32
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/../../../../lib32
-L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/../../..
-L/lib/../lib32 -L/usr/lib/../lib32 /tmp/ccqG9m2o.o -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/32/crtend.o
/usr/lib/../lib32/crtn.o
/usr/lib/../lib32/crt1.o(.text+0xc): In function `_start':
../sysdeps/i386/elf/start.S:92: undefined reference to `__libc_csu_fini'
/usr/lib/../lib32/crt1.o(.text+0x11):../sysdeps/i386/elf/start.S:93:
undefined reference to `__libc_csu_init'
collect2: ld returned 1 exit status

Chris Lu

Re: GCC configure problem with 32-bit stuff on x86_64

[Kai Ruottu]

Chris Lu wrote:
> On 11/15/05, Kai Ruottu <karuottu@mbnet.fi> wrote:
> 
>>> For some reason I have */lib for the 64-bit libs, */lib32 for 32-bit,
 >>> and */lib64 symlinked to */lib.
 >>
>>  The FSF GCC sources seem to expect the Linux/x86_64 installations
>>to have the default 64-bit stuff in '*/lib64' and the 32-bit stuff
>>in '*/lib', so you have a problem to solve with this. What kind of
>>Linux/x86_64 puts its libraries this way?
> I believe Debian and Debian-based distros do (I'm using Ubuntu).

  The Fedora3 and SuSE 9.x Linux/x86_64 I have crosstools to, use this
'GCC standard' for its libraries, Debian and so Ubuntu seem to have
used a different "Linux/*64 standard" (also those PPC64, Sparc64 etc.
other 64-bit Linuces use the same 'GCC standard' in their default
GCCs...). Doesn't sound good...

> $ gcc -o hello -m32 -v hello.c
<snip>
> GNU C version 4.0.2 (x86_64-unknown-linux-gnu)
>         compiled by GNU C version 4.0.2.
> GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128234
>  as -V -Qy --32 -o /tmp/ccqG9m2o.o /tmp/ccWDV8FJ.s
> GNU assembler version 2.15 (x86_64-linux) using BFD version 2.15
>  /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.0.2/collect2
> --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o hello

  The Fedora and SuSE have the '/lib/ld-linux.so.2' for the 32-bit code
and the '/lib64/ld-linux-x86-64.so.2' for the 64-bit code. When your
'/lib64' was symlinked to be seen as '/lib', this '--dynamic-linker'
at least should be ok, in '/lib' you should have both these
'ld-linux*.so.2's...

> /usr/lib/../lib32/crt1.o /usr/lib/../lib32/crti.o
> /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/32/crtbegin.o
> -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/32
> -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2
> -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/../../../../lib32
> -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/../../..
> -L/lib/../lib32 -L/usr/lib/../lib32 /tmp/ccqG9m2o.o -lgcc --as-needed
> -lgcc_s --no-as-needed -lc

The '-lc' here should take the '/usr/lib32/libc.so', which is a linker
script (not a real shared library) and has a 'GROUP' row telling which
(provided with their absolute paths) 'libc.so.6' and 'libc_nonshared.a'
libraries should be linked against...

  -lgcc --as-needed -lgcc_s --no-as-needed
> /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/32/crtend.o
> /usr/lib/../lib32/crtn.o
> /usr/lib/../lib32/crt1.o(.text+0xc): In function `_start':
> .../sysdeps/i386/elf/start.S:92: undefined reference to `__libc_csu_fini'
> /usr/lib/../lib32/crt1.o(.text+0x11):../sysdeps/i386/elf/start.S:93:
> undefined reference to `__libc_csu_init'

These both symbols were in the 'libc_nonshared.a', in the module
'elf-init.oS' in the glibc-2.3.3 coming with Fedora3/x86_64. If
assuming them now being needed there, something is wrong in your
'/usr/lib32/libc.so' script or in that '/usr/lib32/libc_nonshared.a'.
Seeing the latter with :

    nm libc_nonshared.a | grep __libc_csu_

should tell whether they are there or not. If not, doing the same
with the 32-bit 'libc.so.6' and 'ld-linux.so.2' should be tried...
They must be somewhere in these three, 'libc.so.6', 'libc_nonshared.a'
and 'ld-linux.so.2', nothing else (besides the 'crt*.o' startups) will
be linked against as default... Another possibility is that the default
linker script in the GNU linker, seen with the command :

    ld -m elf_i386 -verbose | more

(for the 32-bit case), somehow could define these symbols...

  Generally trying (=learning to use) the '-verbose' during the link
phase is recommended, compiling the "Hello World" using the '-v' is
useful but more useful would be to add the '-verbose' for the link
phase too, like :

    gcc -v -Wl,-verbose -o hello hello.c > LogFile 2>&1

and then browse that (quite long) 'LogFile'... The rule here is the
stuff in those '*/lib32' places should be taken.

  So the "debug the GCC install" tools are listed here, but it is your
homework to try find out the reasons for your problem with them...

  BTW, older glibc-versions (2.2.x) didn't have those '__libc_csu_*'
symbols in their 'libc_nonshared.a's. Maybe 'google'ing for these
could help to tell what they are for... (The 'csu' refers to the
'C Start Up' components in the 'csu' subdir in the glibc sources).






> collect2: ld returned 1 exit status
> 
> Chris Lu
> 
> 

Re: GCC configure problem with 32-bit stuff on x86_64

[Chris Lu]

Hi,

>   The Fedora and SuSE have the '/lib/ld-linux.so.2' for the 32-bit code
> and the '/lib64/ld-linux-x86-64.so.2' for the 64-bit code. When your
> '/lib64' was symlinked to be seen as '/lib', this '--dynamic-linker'
> at least should be ok, in '/lib' you should have both these
> 'ld-linux*.so.2's...

I have the 32-bit ld-linux.so.2 in /lib32, and the 64-bit one in /lib.

> > .../sysdeps/i386/elf/start.S:92: undefined reference to `__libc_csu_fini'
> > /usr/lib/../lib32/crt1.o(.text+0x11):../sysdeps/i386/elf/start.S:93:
> > undefined reference to `__libc_csu_init'
>
> These both symbols were in the 'libc_nonshared.a', in the module
> 'elf-init.oS' in the glibc-2.3.3 coming with Fedora3/x86_64. If
> assuming them now being needed there, something is wrong in your
> '/usr/lib32/libc.so' script or in that '/usr/lib32/libc_nonshared.a'.
> Seeing the latter with :
>
>     nm libc_nonshared.a | grep __libc_csu_

These symbols were in /usr/lib32/libc_nonshared.a. I found that simply
adding -L/usr/lib32 to any gcc command with -m32 solved that problem.
Using that, I compiled a functional 'hello world' program.

Debian may have changed over to the /lib and /lib64 system, but
apparently Ubuntu didn't when I installed it.