Libtorrent: pkgconfig file doesn't contain boost_system lib with cmake

[silverqx]

If I don't pass -DCMAKE_BUILD_TYPE=Release|Debug to cmake build command, I don't have -lboost_system in generated libtorrent-rasterbar.pc file.

I think there should be some defaults, if this option is not passed.

Cmake docs for CMAKE_BUILD_TYPE

[arvidn]

I think it's common to default to debug, but maybe that will just risk a bunch of people running debug builds by mistake

[silverqx]

How this should work if any value is passed to CMAKE_BUILD_TYPE, is this somehow defined by cmake or every project should decide by self.

When I try build with Autotools, so the default is release build.

I think it's common to default to debug

Ok, I try find some info, how this works, I think at the end, we will have to decide what we will have to by default.

The other thing is, that there is something called single-configuration / multi-configuration generators and it will somehow interfere with this.
Makefile Generators and Ninja are single-configuration generators.

[zeule]

I think we should start again with the cmake trace log and the files in the /torrent-rasterbar-pkgconfig subdir (there will be the .pc file too after the install stage).

[silverqx]

I think we should start again with the cmake trace log and the files in the /torrent-rasterbar-pkgconfig subdir (there will be the .pc file too after the install stage).

The problem starts at line 276 in cmake_log.txt, ${configs} is empty and because of that foreach(cfg ${configs}) cycle is skipped and because of that .pc file doesn't contain -lboost-system.

Do you have any idea how to fix this in another way? But I like the idea to fix this by proposed PR #4420

cmake_log.txt
torrent-rasterbar-pkgconfig.zip

[zeule]

I believe there is a mistake in _get_target_property_merging_configs() which needs to be fixed but not work arounded. Unfortunately, I can't reproduce the problem. Do you simply omit -DCMAKE_BUILD_TYPE on the command line, or do you pass empty string? Also, what is your cmake version, please?

[silverqx]

Maybe you have cached CMAKE_BUILD_TYPE, try to remove build dir or if you use in source tree build try git clone, I'm using cd build && rm -rf ./*. You can look by cmake -LH . what values are in your cache.
I'm using cmake 3.16.5 and to generate cmake config cmake . or cmake .. if I am at build/.

Do you simply omit -DCMAKE_BUILD_TYPE on the command line, or do you pass empty string?

Both cases produce this problem.

[zeule]

Thanks, I'm testing with new build dirs and cmake 3.16.5 too:

mkdir build-no-type
cd build-no-type
cmake ..

These commands create a normal torrent-rasterbar-pkgconfig/compile-settings.cmake file:

$ grep _TARGET_INTERFACE_LINK_LIBRARIES torrent-rasterbar-pkgconfig/compile-settings.cmake
set(_TARGET_INTERFACE_LINK_LIBRARIES "-lpthread;/usr/lib64/libssl.so;/usr/lib64/libcrypto.so;/usr/lib64/libboost_system-mt.so")

[silverqx]

This is strange, when I do the same, so there is no /usr/lib64/libboost_system-mt.so.

And I discovered another problem, I have installed release version of boost and when I do cmake -DCMAKE_BUILD_TYPE=Debug, than libboost_system is missing too.
For me, it behaves correctly only with -DCMAKE_BUILD_TYPE=Release.

I'm testing this on Manjaro now, on which distro do you test? Please post here output of cmake -LA .., thx.

[zeule]

Does the torrent library links with the boost one? I'm on Gentoo, and here are my variables:

BUILD_SHARED_LIBS:BOOL=ON
Boost_DIR:PATH=Boost_DIR-NOTFOUND
Boost_INCLUDE_DIR:PATH=/usr/include
Boost_LIBRARY_DIR_DEBUG:PATH=/usr/lib64
Boost_LIBRARY_DIR_RELEASE:PATH=/usr/lib64
Boost_SYSTEM_LIBRARY_DEBUG:FILEPATH=/usr/lib64/libboost_system-mt.so
Boost_SYSTEM_LIBRARY_RELEASE:FILEPATH=/usr/lib64/libboost_system-mt.so
CMAKE_ADDR2LINE:FILEPATH=/usr/bin/addr2line
CMAKE_AR:FILEPATH=/usr/bin/ar
CMAKE_BUILD_TYPE:STRING=
CMAKE_COLOR_MAKEFILE:BOOL=ON
CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++
CMAKE_CXX_COMPILER_AR:FILEPATH=/usr/bin/gcc-ar
CMAKE_CXX_COMPILER_RANLIB:FILEPATH=/usr/bin/gcc-ranlib
CMAKE_CXX_FLAGS:STRING=
CMAKE_CXX_FLAGS_DEBUG:STRING=-g
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
CMAKE_C_COMPILER:FILEPATH=/usr/bin/cc
CMAKE_C_COMPILER_AR:FILEPATH=/usr/bin/gcc-ar
CMAKE_C_COMPILER_RANLIB:FILEPATH=/usr/bin/gcc-ranlib
CMAKE_C_FLAGS:STRING=
CMAKE_C_FLAGS_DEBUG:STRING=-g
CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
CMAKE_DLLTOOL:FILEPATH=CMAKE_DLLTOOL-NOTFOUND
CMAKE_EXE_LINKER_FLAGS:STRING=
CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING=
CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING=
CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING=
CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING=
CMAKE_EXPORT_COMPILE_COMMANDS:BOOL=OFF
CMAKE_INSTALL_BINDIR:PATH=bin
CMAKE_INSTALL_DATADIR:PATH=
CMAKE_INSTALL_DATAROOTDIR:PATH=share
CMAKE_INSTALL_DOCDIR:PATH=
CMAKE_INSTALL_INCLUDEDIR:PATH=include
CMAKE_INSTALL_INFODIR:PATH=
CMAKE_INSTALL_LIBDIR:PATH=lib64
CMAKE_INSTALL_LIBEXECDIR:PATH=libexec
CMAKE_INSTALL_LOCALEDIR:PATH=
CMAKE_INSTALL_LOCALSTATEDIR:PATH=var
CMAKE_INSTALL_MANDIR:PATH=
CMAKE_INSTALL_OLDINCLUDEDIR:PATH=/usr/include
CMAKE_INSTALL_PREFIX:PATH=/usr/local
CMAKE_INSTALL_RUNSTATEDIR:PATH=
CMAKE_INSTALL_SBINDIR:PATH=sbin
CMAKE_INSTALL_SHAREDSTATEDIR:PATH=com
CMAKE_INSTALL_SYSCONFDIR:PATH=etc
CMAKE_LINKER:FILEPATH=/usr/bin/ld
CMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/gmake
CMAKE_MODULE_LINKER_FLAGS:STRING=
CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING=
CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING=
CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING=
CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING=
CMAKE_NM:FILEPATH=/usr/bin/nm
CMAKE_OBJCOPY:FILEPATH=/usr/bin/objcopy
CMAKE_OBJDUMP:FILEPATH=/usr/bin/objdump
CMAKE_RANLIB:FILEPATH=/usr/bin/ranlib
CMAKE_READELF:FILEPATH=/usr/bin/readelf
CMAKE_SHARED_LINKER_FLAGS:STRING=
CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING=
CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING=
CMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING=
CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING=
CMAKE_SKIP_INSTALL_RPATH:BOOL=NO
CMAKE_SKIP_RPATH:BOOL=NO
CMAKE_STATIC_LINKER_FLAGS:STRING=
CMAKE_STATIC_LINKER_FLAGS_DEBUG:STRING=
CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL:STRING=
CMAKE_STATIC_LINKER_FLAGS_RELEASE:STRING=
CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO:STRING=
CMAKE_STRIP:FILEPATH=/usr/bin/strip
CMAKE_VERBOSE_MAKEFILE:BOOL=FALSE
Iconv_INCLUDE_DIR:FILEPATH=
Iconv_LIBRARY:FILEPATH=/usr/lib64/libc.so
OPENSSL_CRYPTO_LIBRARY:FILEPATH=/usr/lib64/libcrypto.so
OPENSSL_INCLUDE_DIR:PATH=/usr/include
OPENSSL_SSL_LIBRARY:FILEPATH=/usr/lib64/libssl.so
PKG_CONFIG_EXECUTABLE:FILEPATH=/usr/bin/pkg-config
build_examples:BOOL=OFF
build_tests:BOOL=OFF
build_tools:BOOL=OFF
deprecated-functions:BOOL=ON
developer-options:BOOL=OFF
dht:BOOL=ON
encryption:BOOL=ON
exceptions:BOOL=ON
extensions:BOOL=ON
i2p:BOOL=ON
logging:BOOL=ON
mutable-torrents:BOOL=ON
pkgcfg_lib__OPENSSL_crypto:FILEPATH=/usr/lib64/libcrypto.so
pkgcfg_lib__OPENSSL_ssl:FILEPATH=/usr/lib64/libssl.so
python-bindings:BOOL=OFF
static_runtime:BOOL=OFF

[silverqx]

~Oh I see it, you have installed both, debug and release version of boost,~ this is how my variables look like, I paste only differences:

Boost_DIR:PATH=/usr/lib64/cmake/Boost-1.72.0
Boost_INCLUDE_DIR:PATH=/usr/include
Boost_SYSTEM_LIBRARY_RELEASE:STRING=/usr/lib64/libboost_system.so.1.72.0

And I have this in output too, which you don't:

boost_headers_DIR:PATH=/usr/lib64/cmake/boost_headers-1.72.0
boost_system_DIR:PATH=/usr/lib64/cmake/boost_system-1.72.0

Does the torrent library links with the boost one?

I build like cmake .. && cmake --build . --target all and below ldd output.

λ ldd libtorrent-rasterbar.so.1.2.5 
        linux-vdso.so.1 (0x00007ffef53e7000)
        libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x00007effa0ada000)
        libboost_system.so.1.72.0 => /usr/lib/libboost_system.so.1.72.0 (0x00007effa0ad5000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007effa0ab3000)
        libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x00007effa07e2000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007effa05f9000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007effa04b3000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007effa02eb000)
        /usr/lib64/ld-linux-x86-64.so.2 (0x00007effa17f1000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007effa02d1000)
        librt.so.1 => /usr/lib/librt.so.1 (0x00007effa02c6000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007effa02c1000)

Linker normally links debug builds against release builds.

For the previous problem, it is important, that your CMAKE_BUILD_TYPE:STRING= is empty and you have correct .pc file for cmake's none configuration, can you pls send output of cmake --trace-expand --trace-source=cmake/Modules/GeneratePkgConfig.cmake -LA .., I want to see how it works at you, thx

[silverqx]

And I don't have this in output, I forgot to paste:

Boost_LIBRARY_DIR_DEBUG:PATH=/usr/lib64
Boost_LIBRARY_DIR_RELEASE:PATH=/usr/lib64
Boost_SYSTEM_LIBRARY_DEBUG:FILEPATH=/usr/lib64/libboost_system-mt.so

[silverqx]

~Oh I see it, you have installed both, debug and release version of boost~

This is not true, your Boost_SYSTEM_LIBRARY_DEBUG and Boost_SYSTEM_LIBRARY_RELEASE points to the same file.

[zeule]

Here is my output, please
cmake_out.txt

[zywo]

I just tested on Arch Linux and Debian unstable:
CMake version:
Arch Linux = 3.17.0
Debian = 3.16.3

libtorrent directory = ~/libtorrent
build directory = ~/build/libt_test
build command = cmake ~/libtorrent

There are some differences on the generated configurations, see the attached files.

diff_archlinux_vs_debian.txt

[silverqx]

Exactly @zywo, I have the same experience, I tried other distros and this problem exists only on arch based distro, I don't know why cmake populates variables this way, may be the problem will be in extra/boost and extra/boost-lib packages.

I have plan to look at it.

[zywo]

Yes, very strange behavior on Arch Linux.

-lboost_system is added to .pc file only when I pass -DCMAKE_BUILD_TYPE=Release

[zeule]

I see the following on Arch:

-- GTP: TYPE of Boost::system is UNKNOWN_LIBRARY
-- GTP: Boost::system[IMPORTED_LOCATION] = 
-- GTP: Boost::system[IMPORTED_LOCATION_DEBUG] = 
-- GTP: Boost::system[IMPORTED_LOCATION_RELEASE] = /usr/lib64/libboost_system.so.1.72.0

which is strange to say the least, as there can no be debug version.

[zeule]

I think we should follow the third paragraph of the IMPORTED_LOCATION docs:

"The IMPORTED_LOCATION target property may be overridden for a given configuration by the configuration-specific IMPORTED_LOCATION_ target property. Furthermore, the MAP_IMPORTED_CONFIG_ target property may be used to map between a project’s configurations and those of an imported target. _If none of these is set_ then the name of any other configuration listed in the IMPORTED_CONFIGURATIONS target property may be selected and its IMPORTED_LOCATION_ value used."

We are in the situation "If none of these is set".

[zeule]

For the record, on Arch Boost::system[IMPORTED_CONFIGURATIONS] = RELEASE

[silverqx]

For the record, on Arch Boost::system[IMPORTED_CONFIGURATIONS] = RELEASE

This is true, when build type was debug? Or what build type was selected

[silverqx]

You are right, this works 🤝 @zeule :

get_target_property(xx ${_target_name} IMPORTED_CONFIGURATIONS)
message("xx: ${xx}")
get_target_property(val_for_cfg_xx  ${_target_name} "${_propert_name}_${xx}")
message("val_for_cfg_xx: ${val_for_cfg_xx}")

Vars values:

_target_name: Boost::system
_propert_name: IMPORTED_LOCATION
xx: RELEASE
val_for_cfg_xx: /usr/lib64/libboost_system.so.1.72.0 🔥

I think, this can be the reason, why the linker correctly links against /usr/lib64/libboost_system.so.1.72.0 release library.

[zeule]

Great! @silverqx, could you then test #4456, please?

[silverqx]

Great! @silverqx, could you then test #4456, please?

Of course, would be my pleasure