This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: GCC configure problem with 32-bit stuff on x86_64
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