Multiple definition of a function in C/C++ code

Question

This is a question on C/C++ function definitions. The code discussed is the static library libRmath that provides the definitions in the Rmath.h header file in R.

The documentation provided for the library states that it is optional for the user to provide the function definition for the function double unif_rand(void).

So my question is if such a function definition is optional, wouldn't there be a problem of multiple function definitions which is not allowed in C/C++?

Edit: It might be tempting to speculate on how things works without looking at the source code, but that is not what I want. I am interested to know how it really works, so you would probably need to read the source code and documentations to answer this question.

Answer 1

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.