linking an executable against a shared library

Question

I have a basic question from which I could not find the solution around. Say that I build a shared library toto made of the following header and source files:

toto.h

void print();

toto.cpp

#include <iostream>
#include "toto.h"
void print()
{
std::cout<<"WHAT A GREAT LIBRARY"<<std::endl;
}

Based on these file I create my shared library using

g++ -fPIC -shared -I. -c toto.cpp -o libtoto.so

Next, I want to use my freshly created shared library in a test file:

test.cpp

#include "toto.h"

int main()
{
    print();
}

to do so, I link my executable against the shared library using

g++ -I. -L. -ltoto test.cpp

and I get my a.out executable file.

When I do a ldd a.out I get the following output:

linux-vdso.so.1 =>  (0x00007fff322f5000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb7e7c24000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb7e7865000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb7e7568000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fb7e7f4d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb7e7352000)

where I do not see any dependency of my executable on toto shared library. Everything seems like during the link process my library has been statically bound to my executable. This seems confirmed by the fact that I can call a.out from everywhere without setting LD_LIBRARY_PATH to the path where my libtoto.so is stored. Is that actually the case ? If so, what did I missed or misunderstand in the aforementioned commands to reach that point?

FYI, this example was run on ubuntu 12.04, g++ 4.6.3

EDIT:

I could find in the meantime that this code produces a "correct" executable in the sense that the ldd displays a dependency on libtoto shared library and that the executable could not be started without setting the LD_LIBRARY_PATH variable:

g++ -I ./mydylib/ -fpic -c mydylib/toto.cpp -o mydylib/toto.o
g++ -shared -o mydylib/libtoto.so mydylib/toto.o
g++ -I ./mydylib/ -L ./mydylib/ test.cpp -ltoto -o ldd_correct

while this one still produces a "wrong" executable with the aforementionned features:

g++ -I ./mydylib -fpic -shared -c mydylib/toto.cpp -o mydylib/libtoto.so
g++ -I ./mydylib -L ./mydylib test.cpp -ltoto -o ldd_wrong

Answer 1

My guess is because it is such a simple library, it was optimised out. Does it still happen with more complex libraries? Have you tried passing a -O0 flag?

I've tried but I can't reproduce the results - my ldd shows

linux-vdso.so.1 =>  (0x00007fffb79fe000)
libtoto.so (0x00007f8a78316000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8a77f2e000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8a77c2a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8a7851a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8a77924000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8a7770d000)

On Ubuntu 14.04 gcc version 4.8.2

However, as I expected, g++ -I. -L. -ltoto test.cpp did not work - I had to run g++ -I. -L. test.cpp -ltoto instead.