problem building Linux software under slackware - Slackware

This is a discussion on problem building Linux software under slackware - Slackware ; Issuing: root@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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: problem building Linux software under slackware

  1. problem building Linux software under slackware

    Issuing:

    root@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

  2. Re: problem building Linux software under slackware

    aku-ankka@ducksburg.ca.us wrote:
    > Issuing:
    >
    > root@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@math.tudelft.nl, fax: +31-15-278 7295 **
    ** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
    ************************************************** ******************

+ Reply to Thread