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
