Linker question

Hello all,

I am currently learning the more intricacies of C and have a question that I am not positive on.

I am developing on Linux platforms and am slightly confused on the mechanics of how the linker actually works. If you could answer these few questions it would help me out a lot.

You obviously have to include relevant .h files for the compiler to do syntax checking, etc, but how does does the linker know which library to pull the symbol from? For instance, if I make a call to strcpy how would the linker actually traverse the library folder to find this? Or would it just go directly to libc?

My latest program is using a decent amount of encryption functions so I am using openssl to do so; when making calls to these functions I was receiving an error that the functions didn't exist until I gave a -lssl flag on gcc to include libssl. I am assuming that by default the linker will only use functions from libc and all user created libraries must be explicitly stated, even if in the same directory? Or am I missing something?

Lastly, what happens if I have a function with the same name and signature as a previous function. How does the linker decide between the two? First it encounters? Or does it simply throw an error? Or a warning?

Anyways, thanks for all your help in advance!
-Ryan

Quote:

You obviously have to include relevant .h files for the compiler to do syntax checking, etc, but how does does the linker know which library to pull the symbol from? For instance, if I make a call to strcpy how would the linker actually traverse the library folder to find this? Or would it just go directly to libc?

My latest program is using a decent amount of encryption functions so I am using openssl to do so; when making calls to these functions I was receiving an error that the functions didn't exist until I gave a -lssl flag on gcc to include libssl. I am assuming that by default the linker will only use functions from libc and all user created libraries must be explicitly stated, even if in the same directory? Or am I missing something?

The linker will not link anything by default; but you're presumably linking with your compiler, which is a slightly different story. The compiler knows that you want to link in libc, so it does that for you. Most standard functions are in libc, so they'll just work with no problem. The exception is standard math functions, which are in libm, so you'll have to link that yourself.

So you are basically correct in assuming that the linker (called by the compiler) will automatically link in the library that provides standard functions. You're on your own for the others.

Quote:

Lastly, what happens if I have a function with the same name and signature as a previous function. How does the linker decide between the two? First it encounters? Or does it simply throw an error? Or a warning?

It depends. Symbols can be “weak”, which means that if another symbol is encountered (say, one you made yourself), it will be preferred. This is regardless of what the prototype for either function is, as the linker has absolutely no concept of prototypes. You could easily override a function with one that's wildly different, causing all sorts of havoc.

I believe that, in the absence of weak symbols, it's first come first serve. But, generally speaking, it's not a good idea to override a symbol. Sometimes it has its uses, but it's a dangerous game. Beware that your compiler might have builtin functions that will override both yours and libc's. Gcc, for example, has a number of builtins. These can be disabled with -fno-builtin.

The above applies to Linux (and, probably, most unixes). According to the C standard, it's against the rules to create functions with the same name as a standard function; the result is undefined behavior, behavior which just happens to have an expected outcome on Linux. There is also no requirement that libm be split off from libc. This is done for historical reasons. There's really no reason to split it off in this day and age, but that's unix-like operating systems for you.

excellent - thank you much!