Hi all, Ettus points at this mailing list as the official forum for raising UHD related questions.
This mail is sent to seek input on a recent regression we are seeing when the official Debian UHD package removed "-lboost_system" from uhd.pc 'Libs' in the following patch: https://sources.debian.org/patches/uhd/3.14.1.0-2/fix-pkg-config/ This results in (among probably other failures) the osmo-trx Debian package failing to build [1], and it has actually been scheduled for removal from debian due to this FTBFS (fail to build from source) [2]. The related Debian bug report for uhd is at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940135 where the Debian package maintainer A. Maitland Bottoms argues his case for why the removal of "-lboost_system" is correct. I'm not sure if that patch has ever been submitted upstream or has been discussed here? I'm looking for some guidance from upstream UHD as to what is the correct course of action. From us as the application developers, it seems rather clear: An application program, like osmo-trx, which doesn't use boost directly, shouldn't have to manually add any boost related libraries to the linker command line. We are using UHD, and we're using pkg-config to tell us what kind of compiler flags and linker command line snippets we should use in order to link against uhd. It's not our responsibility to know about implementation details of UHD and what kind of libraries it may need in terms of its upstream dependencies. I'm not a pkg-config expert, but *if* Debian is right to remove -lboost_system from Libs, then maybe it simply needs to be added to Requires? Both the 'Requires' and the 'Requires.private' lines are empty in libuhd-dev:amd63 3.14.1.0-2 Thanks for any help in advance. Regards, Harald [1] https://osmocom.org/issues/4182 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939974 -- - Harald Welte <lafo...@osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
