RHS Linux User wrote:
> Its embarassing to discover that one doesnt really understand what
> is going on in the compile and link process. This is what I recently found
> out. The command 'gcc huffman.c codeheap.c' goes through perfectly.
> However, the command 'gcc -c huffman.c' and 'gcc -c codeheap.c' followed
> by 'ld huffman.o codeheap.o' gives me the following (on the link) :
[snip]
Using `gcc huffman.o codeheap.o' would have automatically added the
necessary switches to ld. On my system (gcc 2.8.1, glibc-2.0.7pre6),
`gcc foo.o bar.o' results in the command:
ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o
/usr/lib/crti.o /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/crtbegin.o
-L/usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1
-L/usr/i586-pc-linux-gnu/lib foo.o bar.o -lgcc -lc -lgcc
/usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/crtend.o /usr/lib/crtn.o
(all one command).
> This is essentially the same sort of behaviour that I get when I
> do 'gcc huffman.c codeheap.c -nodefaultlibs', leading me to believe that
> the default libraries need to be passed to the linker.
Yep.
> The only question
> is : where are these libraries?
See above.
> I cant locate any files like libc.a. I do know where to find the
> libc.so* files, but I though that these were the runtime libraries.
gcc can link against ELF shared libraries (.so files) directly. There
is no need for `import libraries' as is the case for a.out (.sa files)
or Windows (.lib files).
--
Glynn Clements <[EMAIL PROTECTED]>