Re: crt source files

[Brian Dessent <brian at dessent dot net>]

Tobin Maginnis wrote:

> Thanks much for taking the time to look this up for me. Everything I
> read seemed to say that these support routines were part of libc, so I
> got lost wandering around libraries. I was thinking that maybe they were
> in yet another library that I missed.

On a linux system the package manager knows which package every file
comes from.  Next time, just ask it.  For example on a Debian system:

$ dpkg-query -S crtbegin.o
gcc-3.3: /usr/lib/gcc-lib/i486-linux/3.3.5/crtbegin.o
gcc-3.4: /usr/lib/gcc/i486-linux/3.4.4/64/crtbegin.o
gcc-3.4: /usr/lib/gcc/i486-linux/3.4.4/crtbegin.o

$ dpkg-query -S crt1.o
libc6-dev: /usr/lib/Scrt1.o
libc6-dev: /usr/lib/Mcrt1.o
libc6-dev: /usr/lib/gcrt1.o
libc6-dev: /usr/lib/crt1.o

You can do the same thing with the web, e.g.

<http://packages.debian.org/search?searchon=contents&keywords=crtbegin.o&mode=exactfilename&suite=stable&arch=any>
or
<http://packages.debian.org/search?searchon=contents&keywords=crt1.o&mode=exactfilename&suite=stable&arch=i386>

You can also verify which are part of gcc by simply looking in gcc's
internal lib dir after "make install", e.g.

$ (cd $(dirname $(gcc-4.4 -print-libgcc-file-name)) && ls *.o)
crtbegin.o  crtbeginS.o  crtbeginT.o  crtend.o  crtendS.o 
crtfastmath.o  crtprec32.o  crtprec64.o  crtprec80.o

> It makes much more sense to me to have the crt routines in the compiler,
> I should have looked in there.

The various crt*.o files all serve different purposes.  For example
crt1.o is generally about initializing the C runtime, which concerns
internal details of the C library, and thus it's part of the libc (which
happens to be glibc in this particular case.)  It wouldn't make any
sense for it to be part of gcc because that's a libc-specific thing and
gcc doesn't contain a libc -- it can be used with many different
targets/libcs.  On the other hand crt{begin,end}.o are about running
constructors and destructors which are internal implementation details
of the compiler and how it implements C++ classes.  This is not libc
specific and concerns internal compiler details, so it makes sense that
it's part of the compiler and not part of the libc.

Brian