Pau Espin Pedrol <pes...@sysmocom.de> writes: > osmo-trx fails to build since a few days/weeks ago in Debian testing and > unstable, while it still builds fine in Debian stable. Reported osmo-trx > in Debian can be found in [1] and upstream in [2]. Example of build > failure can be found in Osmocom's OBS repositories for Debian (different > versions available) [3].
... > Main difference seems to be UHD in testing and stable has this extra patch: > https://sources.debian.org/patches/uhd/3.14.1.0-2/fix-pkg-config/ > > I'm not sure why this patch was applied (I don't see a similar patch > applied in UHD master in upstream). Could it be that libboost-system > doesn't exist on some system architectures but it was unconditionally > dropped with that patch? The reason for the patch was that upstream usage violated this rule: https://lintian.debian.org/tags/pkg-config-references-unknown-shared-library.html Since osmo-trx is using boost itself, it ought to handle its own linking. If -lboost_system is in the Libs.private: field of uhd.pc, does osmo-trx build? UHD has a C API. Having pkg-config output -lboost_system seems wrong in that context. Is this bug better fixed by having osmo-trx handle boost linking? This case is made complicated since UHD exposes boost headers in its headers. And Boost does not provide .pc files. A simple main() that calls uhd::get_version_string() and uhd::get_abi_string() links fine using -luhd alone. Re-reading the pkg-config man page, I think the fix-pkg-config patch on uhd is on the right track. There is a case to be made for for adding "Libs.private: -lboost_system" to uhd.pc, but I do not think that solves the osmo-trx build error (unless building a static binary). -Maitland
