problematic GCC crt files

Martin Lubich martin.lubich at
Mon Mar 4 02:01:41 PST 2002

I stumbled across a rather strange problem when upgrading from my LFS 2.4 
based system to glibc 2.2.5. (LFS 2.4 was based on glibc 2.1.3)

Following the build instructions everything went smooth and installed 
properly. But then later on suddenly some configure scripts failed to work. 
Further investigation revealed, that these scripts failed at constructs 
like i.e:

  gcc conftest.c -o conftest -ldl

stating that the symbol _atexit was undefined.

As with glibc 2.2.x this symbol is now statically linked to each 
application requesting it, through the static library libc_nonshared.a. My 
setup was correct and I found out that the shared object library 
(and with it every other shared library) had external references to 

In the upper example the link commands for libdl appears _after_ -lc (which 
resolves to libc_nonshared.a) and therefore I get the unresolved symbol.

Further investigation showed, that the reference to _atexit is generated 
from the gcc runtime file crtendS.o, which is linked in for all shared 
objects, thus generating external refenrences to _atexit for all shared 

A cross check at a SuSE Distribution revealed, that 
 - first: no shared libary had these external references
 - second: even the file crtendS.o was missing these references

The source file to crtendS.o (crtstuff.c) has the following passage:

/* This is a kludge. The i386 GNU/Linux dynamic linker needs ___brk_addr,
   __environ and atexit (). We have to make sure they are in the .dynsym
   section. We accomplish it by making a dummy call here. This
   code is never reached.  */
#if defined(__linux__) && defined(__PIC__) && defined(__i386__)
    extern void *___brk_addr;
    extern char **__environ;

    ___brk_addr = __environ;
    atexit ();

All these macros (__linux__, etc) are all internally compiler defined and 
thus forcing this code to be emitted.

Not knowing what else to do, I just commented out these few lines and 
rebuilt gcc and with that rebuilt glibc.

My system is now running perfectly without any problems so far.

My questions are now

- Is this a correct way to overcome these problems
- Has the current LFS version the same problems when built from scratch
- am I only too dumb to understand what's going on here

Any comments on this are highly appreciated


Martin Lubich

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-support' in the subject header of the message

More information about the lfs-support mailing list