Re: Linking error after switching from g++-4.4 to g++-4.5

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 30 March 2011 11:04, Dmitry Risenberg wrote:
> Hello list!
>
> After switching from g++-4.4 to g++-4.5, my code stopped compiling and
> began reporting errors on linking.
> Here's an example (as is, could not reproduce the error on purpose in
> small example) - parts of the application are compiled as static
> libraries and then linked together with main.cpp.o and shared
> libraries:
> <...>
> /usr/local/bin/c++ ? ?-Wall -g
> CMakeFiles/test_backend.dir/main.cpp.o ?-o test_backend -rdynamic
> liblibtest_backend.a /usr/local/lib/liblog4cplus.so
> /usr/local/lib/libpion-net.so /usr/local/lib/libpion-common.so
> -lboost_regex-mt -lpthread -lxml2 -lboost_program_options-mt
> -lboost_filesystem-mt -lboost_thread-mt /usr/local/lib/libboost_xml.so
> -lboost_system-mt ../Utils/liblibsearch_utils.a
> /usr/local/lib/libcurlpp.so -lxslt ../SearchData/liblibsearch_data.a
> -lboost_filesystem-mt -Wl,-rpath,/usr/local/lib:
>
> The reported error is:
> /usr/bin/ld: liblibtest_backend.a(DocumentGeneratorService.cpp.o):
> undefined reference to symbol 'SSL_write@@OPENSSL_0.9.8'
> /usr/bin/ld: note: 'SSL_write@@OPENSSL_0.9.8' is defined in DSO
> //lib64/libssl.so.0.9.8 so try adding it to the linker command line
> //lib64/libssl.so.0.9.8: could not read symbols: Invalid operation
>
> OK, adding -lssl to the linking list fixes that, but another similar
> error occurs - looks like I'll have to add all dependent shared
> libraries to the list to fix that, so there should be a better way.
>
> Adding --verbose option to compilcation, I get the following output:
> <...>
> COLLECT_GCC_OPTIONS='-v' '-Wall' '-g' '-o' 'test_backend' '-rdynamic'
> '-shared-libgcc' '-mtune=generic' '-march=x86-64'
> ?/usr/lib/gcc/x86_64-linux-gnu/4.5.1/collect2 --build-id
> --no-add-needed --eh-frame-hdr -m elf_x86_64 --hash-style=gnu
> -export-dynamic -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro
> -o test_backend
> /usr/lib/gcc/x86_64-linux-gnu/4.5.1/../../../../lib64/crt1.o
> /usr/lib/gcc/x86_64-linux-gnu/4.5.1/../../../../lib64/crti.o
> /usr/lib/gcc/x86_64-linux-gnu/4.5.1/crtbegin.o
> -L/usr/lib/gcc/x86_64-linux-gnu/4.5.1
> -L/usr/lib/gcc/x86_64-linux-gnu/4.5.1/../../../../lib64
> -L/lib/../lib64 -L/usr/lib/../lib64
> -L/usr/lib/gcc/x86_64-linux-gnu/4.5.1/../../..
> -L/usr/lib/x86_64-linux-gnu CMakeFiles/test_backend.dir/main.cpp.o
> liblibtest_backend.a /usr/local/lib/liblog4cplus.so
> /usr/local/lib/libpion-net.so /usr/local/lib/libpion-common.so
> -lboost_regex-mt -lpthread -lxml2 -lboost_program_options-mt
> -lboost_filesystem-mt -lboost_thread-mt /usr/local/lib/libboost_xml.so
> -lboost_system-mt ../Utils/liblibsearch_utils.a
> /usr/local/lib/libcurlpp.so -lxslt ../SearchData/liblibsearch_data.a
> -lboost_filesystem-mt -rpath /usr/local/lib: -lstdc++ -lm -lgcc_s
> -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/4.5.1/crtend.o
> /usr/lib/gcc/x86_64-linux-gnu/4.5.1/../../../../lib64/crtn.o
>
> OK, --no-add-needed is the offending option and removing it fixes the
> linking. But why did it get there? While I can disable it via
> -Wl,--add-needed, I want to know the root cause for this error and fix
> it.
>
> My system is Linux 2.6.35 (Ubuntu Maverick), gcc (Ubuntu/Linaro
> 4.5.1-7ubuntu2) 4.5.1.

Looks like a change in Ubuntu's GCC package:

https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/031991.html