Currently libosmosdr is needed to compile but is not a dependency at all, yet. To compile, a function osmosdr_set_fpga_iq_swap is needed from libosmosdr which does not exist on branch "master" yet. The introducing commit provide accessors for expanded USB API http://cgit.osmocom.org/cgit/osmo-sdr/commit/?id=4eed4e78708fe7d3e9ad167de4841a684dfe0538 can be found in the recent history of branch "hopscotch": http://cgit.osmocom.org/cgit/osmo-sdr/log/?h=hopscotch I have add a snapshot-based ebuild to betagarden: http://git.overlays.gentoo.org/gitweb/?p=proj/betagarden.git;a=commitdiff;h=ff49cb3bb4bf66240f6503a9c170248dbb95beab I suppose it would be good to start talking to upstream and to move to snapshot ebuilds in Gentoo. Let me know if you need help with it.
gr-osmosdr builds fine without libosmosdr. Only if that is installed, then gr-osmosdr automagically links against it and fails.
Without deep analysis it looks like we have to fix four auto-magic dependencies: ==8<================8<================8<================8<== -- checking for module 'uhd' -- package 'uhd' not found -- Could NOT find UHD (missing: UHD_LIBRARIES UHD_INCLUDE_DIRS) -- checking for module 'gnuradio-uhd' -- package 'gnuradio-uhd' not found -- gnuradio-uhd not found. -- Could NOT find GNURADIO_UHD (missing: GNURADIO_UHD_LIBRARIES GNURADIO_UHD_INCLUDE_DIRS) -- checking for module 'gnuradio-fcd' -- package 'gnuradio-fcd' not found -- gnuradio-fcd not found. -- Could NOT find GNURADIO_FCD (missing: GNURADIO_FCD_LIBRARIES GNURADIO_FCD_INCLUDE_DIRS) -- checking for module 'libosmosdr' -- found libosmosdr, version UNKNOWN -- Found libosmosdr: /usr/include, /usr/lib64/libosmosdr.so ==8<================8<================8<================8<== I have just requested a Trac account upstream.
I have opened two tickets upstream. gr-osmosdr depends on "hopscotch" version of libosmosdr https://sdr.osmocom.org/trac/ticket/10 [Patch] gr-osmosdr: Please allow bypassing/forcing detection of optional dependencies https://sdr.osmocom.org/trac/ticket/11 Let's see how that turns out.
Link changed https://osmocom.org/issues/1475 https://osmocom.org/issues/1476 What should we do now?
(In reply to Jonas Stein from comment #4) > Link changed > https://osmocom.org/issues/1475 > https://osmocom.org/issues/1476 > > What should we do now? I'm CC'ing zerochaos because of his activity on gr-osmosdr-9999.ebuild in 2021. Given that… - both bugs were rejected without a comment upstream *shrug* - live ebuilds are moving targets and do not receive full support in general - gr-osmosdr-9999 has been updated since this issue was created in 2012; these is some chance the issue has been fixed in the meantine - I have not been using gr-osmosdr in recent years …I suggest that we close as obsolete/wontfix/fixed, as you see fits best. @jstein @zerochaos what do you think?
sounds good to me
