problematic GCC crt files
martin.lubich at gmx.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
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 libdl.so
(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;
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
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-support' in the subject header of the message
More information about the lfs-support