Prev: Black google
Next: .bash_history file
From: aku-ankka on 29 Mar 2008 17:34
Issuing:

root(a)aku-ankka:/usr/lib# nm crt1.o
I have

00000004 R _IO_stdin_used
00000000 D __data_start
U __libc_csu_fini
U __libc_csu_init
U __libc_start_main
00000000 R _fp_hw
00000000 T _start
00000000 W data_start
U main


so there are unresolved symbol in my /usr/lib/crt1.o
Since this affects configuring for Makefile in compiling
software from sources, I got the problem to find the reason
of such issue.

Indeed that's the config.log file:

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:613: checking host system type
configure:634: checking target system type
configure:652: checking build system type
configure:712: checking for a BSD compatible install
configure:769: checking for -p flag to install
configure:792: checking whether build environment is sane
configure:830: checking whether make sets ${MAKE}
configure:876: checking for working aclocal-1.4
configure:889: checking for working autoconf
configure:902: checking for working automake-1.4
configure:915: checking for working autoheader
configure:928: checking for working makeinfo
configure:1060: checking for gcc
configure:1173: checking whether the C compiler (gcc ) works
configure:1189: gcc -o conftest conftest.c 1>&5
/usr/lib/gcc/i486-slackware-linux/3.4.6/../../../crt1.o(.text+0xc): In function `_start':
: undefined reference to `__libc_csu_fini'
/usr/lib/gcc/i486-slackware-linux/3.4.6/../../../crt1.o(.text+0x11): In function `_start':
: undefined reference to `__libc_csu_init'
collect2: ld returned 1 exit status
---------------------------------------------------

Note that
crt1.o comes from glibc-2.3.2-i486-6.tar.gz
in my Linux Slackware distribution,
but also from glibc-2.5.1-i486-6.tar.gz isn't different

Does anyone suggest me some way to understand that weird behaviour ?

Thanks,
Aku Ankka
From: Eef Hartman on 30 Mar 2008 10:18
aku-ankka(a)ducksburg.ca.us wrote:
> Issuing:
>
> root(a)aku-ankka:/usr/lib# nm crt1.o
> I have
>
> 00000004 R _IO_stdin_used
> 00000000 D __data_start
> U __libc_csu_fini
> U __libc_csu_init
> U __libc_start_main
> 00000000 R _fp_hw
> 00000000 T _start
> 00000000 W data_start
> U main
>
>
> so there are unresolved symbol in my /usr/lib/crt1.o

That is normal, those symbols will be resolved by the "main()" program
unit (crt1.o is the initialization of the C RunTime system, is automatic
linked in during the BUILD phase of any program).
> configure:1189: gcc -o conftest conftest.c 1>&5
> /usr/lib/gcc/i486-slackware-linux/3.4.6/../../../crt1.o(.text+0xc): In function `_start':

Note that this makefile is trying to use a 3.4.6 version of the C compiler,
while your crt1.o is from the standard 4.1 version (assuming you're using
Slackware 12.0, gcc 4.2 in -current).
Also, your configure was searching for aclocal-1.4, while Slackware has
been using 1.9 of that for a long time (at least since 10.2).

So this looks like a VERY old package, which may need massive adaptions
to be able te get compiled under Slackware.

> crt1.o comes from glibc-2.3.2-i486-6.tar.gz

glibc 2.3.2 is even older: it belongs to gcc 3.2.x

> in my Linux Slackware distribution,
> but also from glibc-2.5.1-i486-6.tar.gz isn't different

And THAT is the correct libc for gcc 4.1.* (4.1.3 I believe).

But anyway, the compiler (gcc) should generate the symbols the
corresponding crt1.o is looking for, while compiling the main()
program unit (ok, some may already be in the "right version"
glibc libraries).

> Does anyone suggest me some way to understand that weird behaviour ?

You've got a mispatch between C compiler(s) and glibc, it seems.
Especially when you got "more then one" gcc version installed you
have to really watch out that each is using its own auxilary files
and glibc version. For gcc 3.x the corresponding glibc normally is
2.3.x (with x being the same digit as the 2nd one of gcc).
glibc 2.4 is for gcc 4.0, 2.5 for 4.1 and -current is already using
glibc 2.7 with a gcc 4.2.x version!!).
--
********************************************************************
** Eef Hartman, Delft University of Technology, dept. EWI/TW **
** e-mail: E.J.M.Hartman(a)math.tudelft.nl, fax: +31-15-278 7295 **
** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
********************************************************************
 | 
Pages: 1
Prev: Black google
Next: .bash_history file