Hi all:
I'm trying to build the latest gr-osmosdr package from the gr3.8 branch, but I'm seeing some unusual errors, and I'm not quite sure what the deal is.
I'll note the following: - I had errors related to existing python2 packages, so I tried building with Python3. I'd be less than surprised if someone says that this is the cause of the issues, but personally, I'd like to roll with the Py3 products from now on, what with Py2 being EOL… - OS is Arch.
My cmake command was: ``` cmake \ -DCMAKE_BUILD_TYPE=Release \ -DPYTHON_EXECUTABLE=$(which python3) \ -DPYTHON_INCLUDE_DIR=$(echo /usr/include/python3*) \ -DPYTHON_LIBRARY=$(echo /usr/lib/libpython3.*.so) \ -DENABLE_DOXYGEN=1 \ -DCMAKE_INSTALL_PREFIX=/usr ../ ```
Output from cmake:
``` -- ###################################################### -- # Gnuradio enabled components -- ###################################################### -- * Python support -- * sysmocom OsmoSDR -- * IQ File Source & Sink -- * Osmocom RTLSDR -- * RTLSDR TCP Client -- * Ettus USRP Devices -- * Osmocom MiriSDR -- * HackRF & rad1o Badge -- * nuand bladeRF -- * RFSPACE Receivers -- * AIRSPY Receiver -- * SoapySDR support -- * Red Pitaya SDR
Coincidentally, I sent a patch for this issue just a moment ago after hitting the same issue.
Regards, Clayton
On Sun, Jan 26, 2020 at 9:36 PM tom@tswartz.net wrote:
Hi all:
I'm trying to build the latest gr-osmosdr package from the gr3.8 branch, but I'm seeing some unusual errors, and I'm not quite sure what the deal is.
I'll note the following:
- I had errors related to existing python2 packages, so I tried building
with Python3. I'd be less than surprised if someone says that this is the cause of the issues, but personally, I'd like to roll with the Py3 products from now on, what with Py2 being EOL…
- OS is Arch.
My cmake command was:
cmake \ -DCMAKE_BUILD_TYPE=Release \ -DPYTHON_EXECUTABLE=$(which python3) \ -DPYTHON_INCLUDE_DIR=$(echo /usr/include/python3*) \ -DPYTHON_LIBRARY=$(echo /usr/lib/libpython3.*.so) \ -DENABLE_DOXYGEN=1 \ -DCMAKE_INSTALL_PREFIX=/usr ../
Output from cmake:
-- ###################################################### -- # Gnuradio enabled components -- ###################################################### -- * Python support -- * sysmocom OsmoSDR -- * IQ File Source & Sink -- * Osmocom RTLSDR -- * RTLSDR TCP Client -- * Ettus USRP Devices -- * Osmocom MiriSDR -- * HackRF & rad1o Badge -- * nuand bladeRF -- * RFSPACE Receivers -- * AIRSPY Receiver -- * SoapySDR support -- * Red Pitaya SDR -- -- ###################################################### -- # Gnuradio disabled components -- ###################################################### -- * Osmocom IQ Imbalance Correction -- * AIRSPY HF+ Receiver -- * FreeSRP support -- -- Building for version: 0.2.0.0 / 0.2.0 -- Using install prefix: /usr -- Configuring done CMake Error at lib/CMakeLists.txt:43 (add_library): Target "gnuradio-osmosdr" links to target "gnuradio::filter" but the target was not found. Perhaps a find_package() call is missing for an IMPORTED target, or an ALIAS target is missing? CMake Error at /usr/lib64/cmake/gnuradio/UseSWIG.cmake:573 (add_library): Target "osmosdr_swig" links to target "gnuradio::filter" but the target was not found. Perhaps a find_package() call is missing for an IMPORTED target, or an ALIAS target is missing? Call Stack (most recent call first): /usr/lib64/cmake/gnuradio/GrSwig.cmake:133 (swig_add_library) swig/CMakeLists.txt:42 (GR_SWIG_MAKE) CMake Error at lib/CMakeLists.txt:43 (add_library): Target "gnuradio-osmosdr" links to target "gnuradio::filter" but the target was not found. Perhaps a find_package() call is missing for an IMPORTED target, or an ALIAS target is missing? -- Generating done CMake Generate step failed. Build files cannot be regenerated correctly.
Any feedback would be appreciated. Thanks,
-- Tom Swartz
I just saw that come across. The messages probably crossed electrons as they were going to the server.
Trying your patch now, will report. Thanks Clayton.
Looks like the patch did the trick. Builds are successful now.
I haven't given it a live test with RX, but after several clean builds and installs, I can say that the package build issue is resolved.