-
Notifications
You must be signed in to change notification settings - Fork 32
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
Comments
The CMakeLists.txt file of Boost.Regex is not relevant; the CMake configuration files are generated by 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. |
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. |
yes, we don't use the |
Should be fixed now, with 7b3fc73. Thank you for the report. |
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:
|
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.
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.
thanks; it has indeed been fixed by 7b3fc73, so I'll close this |
I still had this error. Had to add this line to my CMake file: Was also building using the static libs. Boost 1.75, Homebrew 3.0.1, macOS 11.2 |
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]>
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)
For anyone else who stumbles on this, you can use CMake's alias targets to work around the issue:
The above will cause CMake to point the |
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 cmakeINTERFACE_LINK_LIBRARIES
in 0e39586, but this should not be necessary for libraries that usetarget_link_libraries
with thePRIVATE
keyword, such as boost_regex (the source of the problem in my case).Is it possible to exclude
PRIVATE
ly linked libraries fromINTERFACE_LINK_LIBRARIES
?The text was updated successfully, but these errors were encountered: