Почему GNU ld по-разному разрешает символы при связывании исполняемых файлов с общими объектами?

У меня есть тривиальный фрагмент кода C++, который выглядит примерно так:

#include <boost/timer/timer.hpp>

int main(void) {
    boost::timer::auto_cpu_timer t;
    return 0;
}

Я попытался скомпилировать и связать его (с gcc 4.8.1 и GNU ld 2.23.52.20130828) следующим образом:

$ g++ -o test test.cc -lboost_timer
/usr/bin/ld: /tmp/cc2jP1jv.o: undefined reference to symbol '_ZN5boost6system15system_categoryEv'
/usr/lib/libboost_system.so.1.54.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

Одним из решений является явное упоминание -lboost_system в командной строке, и это работает. Однако я также могу сделать:

$ g++ -Wl,--copy-dt-needed-entries -o test test.cc -lboost_timer

Согласно документации ld «с --copy-dt-needed-entries динамические библиотеки, упомянутые в командной строке, будут рекурсивно искаться, следуя их тегам DT_NEEDED в другие библиотеки, чтобы разрешить символы, требуемые выходным двоичным файлом», поэтому это все имеет смысл: ld выясняет из boost_timer, что ему также необходимо связать с boost_system, чтобы разрешить все символы.

Однако я понял, что это тоже работает:

$ g++ -fPIC -shared -o test test.cc -lboost_timer

Очевидно, теперь я создал общий объект, а не исполняемый файл. Однако, по-видимому, ld смог выяснить, что ему нужно связать общий объект с boost_system:

$ ldd test | grep boost_system
        libboost_system.so.1.54.0 => /usr/lib/libboost_system.so.1.54.0 (0x00007f385246e000)

Итак, мой вопрос заключается в следующем: почему разрешение символов отличается при создании общего объекта по сравнению с исполняемым файлом? Как ld может понять, что мой общий объект должен быть связан с boost_system без моего указания --copy-dt-needed-entries?