Non-boost dependencies included in INTERFACE_LINK_LIBRARIES for shared libraries

[scpeters]

Recently boost 1.75.0 was added to homebrew-core in https://github.com/Homebrew/homebrew-core/pull/66792, after which I started noticing some failures in some of my software that links against boost (https://github.com/osrf/homebrew-simulation/issues/1235) with linking errors like ld: library not found for -licudata. I believe part of the reason is that all non-Boost dependencies were added to the cmake INTERFACE_LINK_LIBRARIES in https://github.com/boostorg/boost_install/commit/0e395865f1e1fb66b50d95faf11189705c60520d, but this should not be necessary for libraries that use target_link_libraries with the PRIVATE keyword, such as boost_regex (the source of the problem in my case).

Is it possible to exclude PRIVATEly linked libraries from INTERFACE_LINK_LIBRARIES?

[pdimov]

The CMakeLists.txt file of Boost.Regex is not relevant; the CMake configuration files are generated by b2 install on the basis of the libraries' Jamfiles. In this specific case, I believe the relevant portion is https://github.com/boostorg/regex/blob/da23154da47ba8788aa10e4266037951ea75fc99/build/Jamfile.v2#L105-L115 which applies when Boost.Regex is built with ICU support.

Even for "private" use it's necessary to link to the dependent library when linking statically, and it's been a request to make the config files do that automatically, as otherwise you needed to link by hand in CMakeLists.txt which didn't guarantee the correct library order.

I suppose this used to work for you before because your use of Boost.Regex did not need any ICU functionality.

[pdimov]

Although on second thought, I probably shouldn't be adding these dependencies to the shared Boost library targets, only to the static ones.

[scpeters]

I suppose this used to work for you before because your use of Boost.Regex did not need any ICU functionality.

Although on second thought, I probably shouldn't be adding these dependencies to the shared Boost library targets, only to the static ones.

yeah, my software links to the shared libraries.

[scpeters]

I suppose this used to work for you before because your use of Boost.Regex did not need any ICU functionality.

yes, we don't use the boost/regex/icu.hpp header

[pdimov]

Should be fixed now, with https://github.com/boostorg/boost_install/commit/7b3fc734242eea9af734d6cd8ccb3d8f6b64c5b2. Thank you for the report.

[mahrud]

I'm not sure if I understand the comments above. Why should the dependencies be listed when linking with the static Boost.Regex library?

We ran into a similar issue, see this comment, which seems to be because of this part of the compile command:

... /usr/local/lib/libboost_regex-mt.a  -licudata  -licui18n  -licuuc ...

[scpeters]

thanks; it has indeed been fixed by 7b3fc73, so I'll close this

[YoussefVictor]

I still had this error. Had to add this line to my CMake file: set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -L/usr/local/opt/icu4c/lib -I/usr/local/opt/icu4c/include")

Was also building using the static libs. Boost 1.75, Homebrew 3.0.1, macOS 11.2

[aws-taylor]

For anyone else who stumbles on this, you can use CMake's alias targets to work around the issue:

find_packge(Boost COMPONENTS regex REQUIRED)
find_package(ICU COMPONENTS uc i18n data REQUIRED)
add_library(icuuc ALIAS ICU::uc)
add_library(icui18n ALIAS ICU::i18n)
add_library(icudata ALIAS ICU::data)

The above will cause CMake to point the icuuc injected by Boost to the actual location found by FindICU.