Hi Harald - Mait & I talked about this issue during GRCon19 a few weeks ago. I believe we came to the same conclusions as you note: A project that does not otherwise require non-UHD library/ies should not have to know to link against them (nor how). The linkage should be provided transparently by CMake or pkgconfig or whatever: variables are returned from "find"ing UHD that provides CFLAGS, CXXFLAGS, LDFLAGS, LIBRARIES, LIBRARY_DIRS, INCLUDE_DIRS, and so forth. These variables can then be used as-is by the calling project without having to know anything else about how the API or ABI is built, installed, or used beyond these variables. The correct way to do this varies depending on which "find" is used. For pkgconfig, using "Requires.private" or "Requires" or just leaving the linkage as before the patch ... any of those might work. But, yes, the bottom line is that the patch you note isn't doing the right thing and needs to be either fixed or removed. I'm leaving it to Mait to deal with this as he sees fit; I think we'd all prefer this get done sooner rather than later. - MLD
On Mon, Sep 30, 2019 at 2:34 AM Harald Welte <lafo...@osmocom.org> wrote: > 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 > -- Michael Dickens Ettus Research Technical Support Email: supp...@ettus.com Web: https://ettus.com/
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
