1

We are having a strange problem when linking a shared library (Foo) with another internal static library (Bar). Bot libraries are built on the same machine within the same CMake build directory.

It is clear that code in shared libraries must be position independent, so we set PIC on any static library dependencies like so:

set_property(TARGET Bar PROPERTY POSITION_INDEPENDENT_CODE True)

And we link the library in the regular way, using target_link_libraries(Foo PUBLIC Bar).

This works fine with GCC 4.8, ld 2.22 and CMake 3.10.1.

However, for some reason, with GCC 7, ld 2.29.1 and CMake 3.10.2 linking fails with multiple undefined reference errors for different functions in Bar. The functions are defined and implemented in Bar, used Foo and the whole thing compiles with GCC4.8. So what gives?

We are also aware of the dual ABI situation and potential issues with std::string. (See https://stackoverflow.com/a/49119902/2095190) However the error does not fit the pattern.

I have some thoughts, though none of them explain why it works with the older toolchain:

Our project is relatively complex, I will try to isolate the error next week.

gordonk
  • 435
  • 3
  • 13
  • You're not trying to mix the compiler versions, i.e. one library with 4.8 and one with 7? Can you check the Bar library with objdump to see if the symbol it's looking for is there and mangled differently, or missing? Can you check the Foo library with objdump too to see what it thinks the symbol it's trying to link to is called? – Rup Mar 28 '19 at 10:25
  • I run cmake / make on two different machines and both libraries are built from source in the same build dir at the same time. So no, I am not mixing compiler versions. I will run objdump and return with more info! – gordonk Mar 28 '19 at 10:33
  • Thanks! I possibly meant nm - sorry if I've got the tools mixed up. – Rup Mar 28 '19 at 10:41
  • Please, provide [mcve] - a small code, which reproduces the error you got, and provide **exact error message**. Otherwise it is a **guessing game** about what else could be wrong with the code or setup without viewing them. – Tsyvarev Mar 28 '19 at 11:45
  • 1
    @Rup well that was easy, I was not expecting anything new from `objdump` but after running it I noticed that - lo and behold - there are cxx11 symbols where there should not be. The issue was that the `_GLIBCXX_USE_CXX11_ABI=0` define was being propagated to Foo by another build target, but not to Bar. (just to be clear, gcc4.8 uses the old ABI by default, which is why there was no error) I feel like an idiot for not running strings or objdump on the *.a file now... I will create a MCV example next week and post the answer. – gordonk Mar 28 '19 at 14:27

0 Answers0