When you application is linked, unresolved symbols will be resolved using the libraries you provide. If you don't define a function, it will be an unresolved symbol during linking, therefore, the linked will try to resolve that symbol using librmath, in this case. If one or more symbols can't be resolved, you'll get a linker error.
However, if you do define the function in your code, it will be already defined during linking, so there will be no need to resolve it using symbols from external libraries.
What you can't do is to define the same symbol more than once in your application.
Edit: Since there is a lot of debate in another answer, i've made a practical example. I've created a shared object(similar to a DLL in windows), which defines and exports a function foo:
//lib.h
extern "C" {
void foo();
void bar();
};
//lib.cpp
#include <iostream>
#include "lib.h"
void foo() {
std::cout << "From lib\n";
}
void bar() {
std::cout << "Bar, calling foo\n";
foo();
}
In order to test this shared object, i've created an application which is linked with it:
//test.cpp
#include <iostream>
#include "lib.h"
void foo() {
std::cout << "From app\n";
}
int main() {
bar();
}
I've compiled both, the shared object and the application:
g++ lib.cpp -o libtest.so -Wall -fPIC -shared -Wl,--export-dynamic -Wl,-soname,libtest.so -Wl,-z,defs
g++ test.cpp -o test -L. -ltest
And when i execute test, setting the library path to ".", so my shared object can be loaded, i get this output:
matias@master:/tmp$ LD_LIBRARY_PATH="." ./test
Bar, calling foo
From app
As you can see, the foo function defined in the application(not the shared object) is called. You can basically do this for every exported symbol in a shared object.
EDIT2: i've added another exported function in lib.h. The application now calls this function, which ends up calling foo. The result is the same, as expected.
EDIT3: Ok, let's go deeper. This is the dump from function bar:
Dump of assembler code for function bar@plt:
0x0804855c <+0>: jmp DWORD PTR ds:0x804a004
0x08048562 <+6>: push 0x8
0x08048567 <+11>: jmp 0x804853c
If we go to address 0x804a004:
Dump of assembler code for function _GLOBAL_OFFSET_TABLE_:
0x08049ff4 <+0>: or BYTE PTR [edi+0x804],bl
0x08049ffa <+6>: add BYTE PTR [eax],al
0x08049ffc <+8>: add BYTE PTR [eax],al
0x08049ffe <+10>: add BYTE PTR [eax],al
.....
As you can see, it's jumping to the Global Offset Table. You can read about the GOT here and here. Dynamic symbols(which are resolved at runtime) are stored in this table. Whenever you call a symbol that should be resolved at runtime, you actually jump to this table, and then jump to the address that is stored in the this table's corresponding entry. Since the application defines foo, the GOT contains the address of the definition from test.cpp, not the one in our shared object.
EDIT4: Okay, last edit. Quoting from the documentation:
You will need to supply the uniform random number generator
double unif_rand(void)
or use the one supplied (and with a dynamic library or DLL you will
have to use the one supplied(...)
The documentation clearly says that you cannot provide you own implementation of unif_rand if you're using the dynamic library. Therefore, i believe that what i pointed out, actually answers your question.
