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]>

Reply via email to