Tobin Maginnis wrote: Note: You seem to be referring to Linux here. These things vary greatly from target to target so you have to be specific about what you're talking about. > collect2 - A hack for object oriented languages (C++) to call a second Part of gcc, see gcc/collect2.c. > ld - Called by collect2. It is the linking loader which combines the Part of binutils. The linker is heavily templatized, see e.g. ld/emultempl/elf32.em. The best way to see how the pieces fit together is to simply build binutils and then look at the build logs. > ld-linux.so.2 - Dynamic loader linked (combined) into your program. Part of glibc, see libc/elf/dl-*.c. > crt0.o - C Run-Time Zero launcher. Used with "ar" absolute archive > library file formats. > > crt1.o - C Run-Time One launcher. Used with ELF dynamic library formats. > Starts a location zero where the OS will begin execution. Jumps to main() > > crti.o - C Run-Time Initialize? launcher. Used for odd processor > architecture initialization. These are all part of glibc. If you are looking for source files with the same filename as the crt*.o files you won't find them. They are all built from common sources, see e.g. libc/csu/libc-start.c and read the Makefile. > crtbegin.o - Used to execute functions located in the ".init" section > which call Java static data constructors. > /tmp/ccPzplAb.o - Your temporary relocatable object file. > > crtend.o - Used to execute functions located in the ".fini" section > which calls Java data destructors. These are part of gcc. Again, you won't find source files with these filenames as they are built from a common file compiled with different combinations of things #defined, see gcc/crtstuff.c. > crtn.o - Closes any open file descriptors and returns to the operating > system via the exit() service. Part of glibc, as above. > I cannot find these files in binutils-2.17.tar.gz, glibc-2.4.tar.gz, or > libtool-2.2.tar.gz I don't know why you'd look in libtool, as that has nothing to do with any of the above. It is simply an optional portability helper for the build environment that is typically used in conjunction with autoconf and automake in order to write portable build systems. It is mostly just shell scripts and m4 macros, although it does include a small C library (libltdl) that abstracts away the differences between the various dlopen()-type APIs of many platforms. Brian