11

I am porting an AutoTools project to CMake.

What AutoTools does:

  • builds some static libraries
  • builds some shared libraries and links static ones into shared
  • builds an executable, links it to shared libraries

What I've managed to do with CMake:

  • build some static libraries - add_library(staticfoo <src>)
  • build some shared libraries - add_library(sharedfoo SHARED <src>) and link them - target_link_libraries(sharedfoo staticfoo)
  • build an executable, link it to shared libraries - target_link_libraries(exe sharedfoo), but that dragged the static libraries in again, too.

So, the resulting link command for the executable has static libs in addition to shared. Which doesn't correspond to the command generated by AutoTools project.

I've tried target_link_libraries(sharedfoo PRIVATE staticfoo), but that doesn't get the symbols from the static lib into the interface of the shared lib.

How to get the symbols without that 'transitive' behavior?

(in platform-independent way)

Carlo Wood
  • 5,648
  • 2
  • 35
  • 47
Velkan
  • 7,067
  • 6
  • 43
  • 87

4 Answers4

8

As I know, CMake doesn't allow to mix STATIC and SHARED libraries.

If your staticfoo library is used solely as part of other libraries/executables, you can define it as

add_library(staticfoo OBJECT <src>)

and use then as some sort of sources when build other library:

add_library(sharedfoo SHARED <src> $<TARGET_OBJECTS:staticfoo>)

For more info see documentation on add_library.

Tsyvarev
  • 60,011
  • 17
  • 110
  • 153
  • CMake don't care what kind of libraries you've tried to link static/dynamic/mixed... that would be a problem of a linker at particular platform. – zaufi Jul 20 '15 at 04:51
  • On windows, the linker discards export symbols by linking archieved objects/static libraries, but unpacked objects work. That's one of the main reasons why object libraries were added to cmake. – Youka Jul 20 '15 at 06:32
  • Indeed this is a good way to convert that pattern found in autotools projects. For alternatives and their issues see this well-detailed question: http://stackoverflow.com/questions/5136184/linking-windows-dll-files-from-static-libraries-using-cmake-without-hand-craftin – tamas.kenez Jul 20 '15 at 14:41
  • 1
    Additionally, I needed to enable position independent code for the static library using `set_property(TARGET staticfoo PROPERTY POSITION_INDEPENDENT_CODE ON)`. See https://stackoverflow.com/questions/38296756/what-is-the-idiomatic-way-in-cmake-to-add-the-fpic-compiler-option. – Chris_128 Jun 30 '21 at 14:29
4

To resolve this case you need to do few things:

  • first of all make sure you've compiled static libraries w/ -fPIC, so they'll contain a relocatable code (which would be a part of a shared library later)
  • then, you need to control symbols visibility when compiling all libraries, so being a part of shared library, symbols came from the static one would be visible
  • and finally, yes, you need to specify PRIVATE <static libs> when linking your shared library, so the linker command line for your executable wouldn't have any static libs
zaufi
  • 6,811
  • 26
  • 34
  • So, how to 'control symbols visibility'? – Velkan Jul 20 '15 at 09:30
  • most obvious way is to use `-fvisibility` [compiler option](https://gcc.gnu.org/wiki/Visibility). CMake >= 3.x has [`CMAKE__VISIBILITY_PRESET`](http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_LANG_VISIBILITY_PRESET.html) variable (and corresponding [target property](http://www.cmake.org/cmake/help/v3.0/prop_tgt/LANG_VISIBILITY_PRESET.html)). But unfortunately it doesn't affect static libraries. That is a lack and will be fixed in upcoming release of [CMake 3.3](http://www.kitware.com/blog/home/post/934). – zaufi Jul 20 '15 at 15:01
2

See my answer here. Basically add /WHOLEARCHIVE, -all_load, or --whole-archive to the linker flags.

Community
  • 1
  • 1
Timmmm
  • 88,195
  • 71
  • 364
  • 509
0

I created a little example that does this the right way, here: https://github.com/CarloWood/cmaketest

It shows how two "static" libraries, one with two visible symbols, both with by default hidden symbols, are added to a shared library, which is then used to link an executable.

The method used is that of @Tsyvarev, combined with the VISIBILITY target property mentioned by @Zaufi.

The only non-platform specific thing (I think) is the __EXPORT macro that is used. It would be nice to fix that too, if anyone knows how.

Carlo Wood
  • 5,648
  • 2
  • 35
  • 47