Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-boost dependencies included in INTERFACE_LINK_LIBRARIES for shared libraries #47

Closed
scpeters opened this issue Dec 22, 2020 · 9 comments

Comments

@scpeters
Copy link

Recently boost 1.75.0 was added to homebrew-core in Homebrew/homebrew-core#66792, after which I started noticing some failures in some of my software that links against boost (osrf/homebrew-simulation#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 0e39586, 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
Copy link
Member

pdimov commented Dec 22, 2020

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
Copy link
Member

pdimov commented Dec 22, 2020

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

@scpeters
Copy link
Author

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 scpeters changed the title Private non-boost dependencies included in INTERFACE_LINK_LIBRARIES Private non-boost dependencies included in INTERFACE_LINK_LIBRARIES for shared libraries Dec 22, 2020
@scpeters scpeters changed the title Private non-boost dependencies included in INTERFACE_LINK_LIBRARIES for shared libraries Non-boost dependencies included in INTERFACE_LINK_LIBRARIES for shared libraries Dec 22, 2020
@scpeters
Copy link
Author

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
Copy link
Member

pdimov commented Dec 23, 2020

Should be fixed now, with 7b3fc73. Thank you for the report.

@mahrud
Copy link

mahrud commented Jan 1, 2021

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 ...

carlocab pushed a commit to scpeters/homebrew-core that referenced this issue Jan 1, 2021
In boost 1.75.0, the cmake INTERFACE_LINK_LIBRARIESS now
include non-boost dependencies like libicudata from the
keg-only formula icu4c. This introduces linking errors
for software that previously linked successfully in brew
against boost 1.74.0 shared libraries (see Homebrew#67427 and
boostorg/boost_install#47).

This adds a patch to the boost formula that has been merged
upstream to limit the expansion of INTERFACE_LINK_LIBRARIES
to boost's static libraries, so that the linking errors
with shared libraries are resolved.
BrewTestBot pushed a commit to Homebrew/homebrew-core that referenced this issue Jan 3, 2021
In boost 1.75.0, the cmake INTERFACE_LINK_LIBRARIESS now
include non-boost dependencies like libicudata from the
keg-only formula icu4c. This introduces linking errors
for software that previously linked successfully in brew
against boost 1.74.0 shared libraries (see #67427 and
boostorg/boost_install#47).

This adds a patch to the boost formula that has been merged
upstream to limit the expansion of INTERFACE_LINK_LIBRARIES
to boost's static libraries, so that the linking errors
with shared libraries are resolved.
@scpeters
Copy link
Author

scpeters commented Jan 4, 2021

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

@scpeters scpeters closed this as completed Jan 4, 2021
@YoussefVictor
Copy link

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

petrutlucian94 added a commit to petrutlucian94/ceph that referenced this issue May 7, 2021
The Windows build is hitting linking errors after
bumping the Boost version to 1.75. The issue is that Boost
is now setting the zlib dependecy using INTERFACE_LINK_LIBRARIES,
which means that it's no longer located using the standard
"find_package" mechanism.

In order for the linker to locate zlib, we'll add it to the
linker search path.

[1] boostorg/boost_install#47

Signed-off-by: Lucian Petrut <[email protected]>
petrutlucian94 added a commit to petrutlucian94/ceph that referenced this issue May 10, 2021
The Windows build is hitting linking errors after
bumping the Boost version to 1.75. The issue is that Boost
is now setting the zlib dependecy using INTERFACE_LINK_LIBRARIES,
which means that it's no longer located using the standard
"find_package" mechanism.

In order for the linker to locate zlib, we'll add it to the
linker search path.

[1] boostorg/boost_install#47

Signed-off-by: Lucian Petrut <[email protected]>
(cherry picked from commit 0af38d1)
@aws-taylor
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants