6

I have 2 libraries: test.1 and test.2. Both libraries contain a single global extern "C" void f(); function, with different implementations (just a cout for the test).

I did the following test:

Test 1 Dynamic linking:
If I add libtest.1.so and then libtest.2.so in the makefile of the executable and then call f(); in main, libtest.1.so->f() is called.
If I change the order in the makefile, libtest.2.so->f() is called

Test 2 Static linking:
Absolutely the same happens with static libraries

Test 3 Dynamic loading
As the library is manually loaded, everything works as expected.

I expected an error for multiple definitions, which obviously didn't happen.

Also, this does not break the one-definition-rule, as the situation is different.

It's also not a dependency-hell(not that it's related to this at all), nor any linking fiasco..

So, than what is this? Undefined behavior? Unspecified behavior? Or it really does depend on the linking order?

And is there a way to easily detect such situations?

Related questions:
dlopen vs linking overhead
What is the difference between dynamic linking and dynamic loading
Is there a downside to using -Bsymbolic-functions?
Why does the order in which libraries are linked sometimes cause errors in GCC?
linking two shared libraries with some of the same symbols

EDIT I did two more tests, which confirm this UB:

I added a second function void g() in test.1 and NOT in test.2.

Using dynamic linking and .so libs, the same happens - f is called with the same manner, g is also executable (as expected).

But using static linking now changes the things: if test.1 is before test.2, there are no errors, both functions from test.1 are called.
But when the order is changed, "multiple definitions" error occurs.

It's clear, that "no diagnostic required" (see @MarkB's answer), but it's "strange" that sometimes the error occurs, sometimes - it doesn't.

Anyway, the answer is pretty clear and explains everything above - UB.

Community
  • 1
  • 1
Kiril Kirov
  • 37,467
  • 22
  • 115
  • 187
  • 1
    /me thinks the standard you should be checking this behavior against is the ELF standard, not the C++ standard. – ninjalj Mar 16 '15 at 19:54

2 Answers2

13

A library is a collection of object files. The linker extracts objects from libraries as necessary to satisfy unresolved symbols. What is important, the linker inspects libraries in the order they appear on a command line, looks into each library just once (unless the command line mentions the library more than once), and takes only objects which satisfy some reference.

In your first set of tests, everything is clear: the linker satisfies a reference to f() from the first available library, and that's pretty much it.

Now the second set of tests. In the success case test.1 satisfies both f and g references, so test.2 is irrelevant. In the failure case, test.2 satisfies the f reference, but g remains undefined. To satisfy g, linker must pull some object from test.1, which also happen to supply f. Obviously it is multiple definition.

Notice that in order to have an error you must have f and g in the same object. If test.1 is composed of 2 objects (one defining f and another defining g) the error disappears.

user58697
  • 7,808
  • 1
  • 14
  • 28
2

This absolutely violates the one definition rule in cases 1&2. In case 3, since you explicitly specify which version of the function to execute it may or may not. Violating the ODR is undefined behavior, no diagnostic required.

3.2/3:

Every program shall contain exactly one definition of every non-inline function or variable that is odr-used in that program; no diagnostic required.

Mark B
  • 95,107
  • 10
  • 109
  • 188
  • Hm.. Now I'm not sure why and how I decided that this does not break the ODR.. But it still bothers me why there's no error for this, as the linker clearly sees the two definitions in this case (not that it must, but still). So, if these functions are not global, but some "internal", `-Bsymbolic` "solves" this? – Kiril Kirov Mar 16 '15 at 15:00
  • ODR is a rule for the compiler, why would it be related to linking? – Cris Luengo Oct 26 '18 at 15:28