Tuesday, February 7, 2023

Re: compiling GR 3.10.5.1 with ENABLE_GR_SOAPY=ON

You can also try adding:

-DCMAKE_FIND_DEBUG_MODE=ON

to your cmake invocation. This will dump where cmake is trying to find
package files.

If you really get stuck, it may be useful to use a more common install
prefix. Cmake will default to /usr/local and /opt.

I'm a big fan of using /opt. It's very easy to delete installs in /opt
versus /usr/local.

Ron

On 2/7/23 18:20, aardric@aardvarr.ca wrote:
> That looked promising but produced the same result.
> I found this line in the CMakeCache.txt:
>
> //No help, variable specified on the command line.
> CMAKE_PREFIX_PATH:UNINITIALIZED=~/.local
>
> which I don't understand.
>
> I certainly appreciate the suggestions and it encourages me to keep
> plugging away. It will be a learning experience for sure.
>
> Rick
>
> On 2023-02-07 14:27, Ron Economos wrote:
>> This is just a guess, but you could try adding:
>>
>> -DCMAKE_PREFIX_PATH=~/.local
>>
>> to your cmake invocation.
>>
>> Ron
>>
>> On 2/7/23 11:56, aardric wrote:
>>> Ryan,
>>> Here is an excerpt of the CMake output:
>>> --
>>> -- Configuring gr-soapy support...
>>> -- Dependency SoapySDR_FOUND = 1
>>> -- Dependency ENABLE_GNURADIO_RUNTIME = ON
>>> -- Enabling gr-soapy support.
>>> -- Override with -DENABLE_GR_SOAPY=ON/OFF
>>> -- SOAPY Version: 0.7.2-unknown
>>> -- No C++ unit tests... skipping
>>> --
>>>
>>> Rick
>>>
>>> On 2023-02-07 11:12, aardric wrote:
>>>> Hail,
>>>>   Your feedback goes beyond my expectations. Before I follow this
>>>> further, here is a summary of my installation attempt as Marcus
>>>> requested. I hope that it is a good balance between detail and clutter.
>>>>
>>>> First to clarify, by 'local' I mean under my home directory (no
>>>> superuser install). The OS is opensuse Leap 15.4.
>>>> The required Type.h and Types.hpp are in the directory:
>>>> > ls ~/.local/include
>>>> gnuradio  lime  pmt  SoapySDR
>>>>
>>>> The sequence of the installation is as follows:
>>>>
>>>> (1) gnuradio 3.10.5.1 was installed in the usual manner from the cloned
>>>> repository.
>>>> gnuradio/build> cmake -DCMAKE_INSTALL_PREFIX=~/.local
>>>> -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3
>>>> -DBoost_LIBRARY_DIRS=/usr/lib64 -DQWT_LIBRARIES=/usr/lib64/libqwt.so.6
>>>> -DQWT_INCLUDE_DIRS=/usr/include/qt5/qwt6 -DENABLE_GR_UHD=OFF
>>>> -DZEROMQ_LIBRARIES=/usr/local/lib64/libzmq.so
>>>> -DZEROMQ_INCLUDE_DIRS=/usr/local/include -DENABLE_GR_SOAPY=OFF ../
>>>>
>>>> Environment variables:
>>>> LD_LIBRARY_PATH="~/.local/lib"
>>>> PYTHONPATH="~/.local/lib64/python3.6/site-packages"
>>>>
>>>> The installation worked as expected.
>>>>
>>>> (2) The distro version of soapySDR (branch 0.8) was NOT installed as per
>>>> the recommendation of
>>>> https://wiki.gnuradio.org/index.php/Soapy#gr-osmosdr%20(Ref:%20https://github.com/pothosware/SoapySDR/wiki/BuildGuide
>>>>
>>>> SoapySDR-soapy-sdr-0.7.2 was built and installed from a downloaded
>>>> archive file.
>>>>
>>>> SoapySDR-soapy-sdr-0.7.2/build> cmake
>>>> -DCMAKE_INSTALL_PREFIX:PATH=~/.local -DENABLE_PYTHON3=OFF
>>>> Executing SoapySDRUtil worked as expected.
>>>>
>>>> (3) LimeSuite 20.10.0 built and installed from downloaded archive file.
>>>> LimeSuite-20.10.0/builddir>  cmake -DCMAKE_INSTALL_PREFIX:PATH=~/.local
>>>> -DENABLE_GUI=ON -DENABLE_UTILITIES=ON -DENABLE_SOAPY_LMS7=ON ../
>>>>
>>>> Executing SoapySDRUtil and LimeUtil found hardware and reported as
>>>> expected.
>>>>
>>>> (4) gnuradio build directory was emptied and CMakeCache.txt deleted.
>>>> gnuradio/build> cmake -DCMAKE_INSTALL_PREFIX=~/.local
>>>> -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3
>>>> -DBoost_LIBRARY_DIRS=/usr/lib64 -DQWT_LIBRARIES=/usr/lib64/libqwt.so.6
>>>> -DQWT_INCLUDE_DIRS=/usr/include/qt5/qwt6 -DENABLE_GR_UHD=OFF
>>>> -DZEROMQ_LIBRARIES=/usr/local/lib64/libzmq.so
>>>> -DZEROMQ_INCLUDE_DIRS=/usr/local/include -DENABLE_GR_SOAPY=ON ../
>>>>
>>>> Configuration by cmake did not show errors but
>>>> gnuradio/build> make -j4
>>>> results in error on missing <SoapySDR/Types.hpp> as mentioned below.
>>>> More details upon request.
>>>>
>>>> cheers,
>>>> Rick
>>>>
>>>>
>>>> On 2023-02-07 10:48, Ryan Volz wrote:
>>>>> Hi all,
>>>>>
>>>>> GNU Radio's cmake scripts do check for this situation (SoapySDR not
>>>>> found, GR_ENABLE_SOAPY force-enabled) and it should error out when
>>>>> `cmake` is run:
>>>>>
>>>>> https://github.com/gnuradio/gnuradio/blob/main/cmake/Modules/GrComponent.cmake#L71
>>>>>
>>>>> The full CMake output would be useful to figuring out why that didn't
>>>>> happen. As far as I can tell, CMake should not "find" SoapySDR if its
>>>>> headers are missing, but maybe that's where it is going wrong.
>>>>>
>>>>> Cheers,
>>>>> Ryan
>>>>>
>>>>> On 2/7/23 5:14 AM, Marcus Müller wrote:
>>>>>> Hi Ron, Hi Rick,
>>>>>>
>>>>>> agreed, you probably need that development package. Problem: Without it,
>>>>>> the GNU Radio build infrastructure shouldn't even allow for enabling of
>>>>>> the SoapySDR components.
>>>>>>
>>>>>> So, Rick, could you tell us which operating system/distro this is on,
>>>>>> and how you did that local installation of SoapySDR, precisely?
>>>>>>
>>>>>> Best regards,
>>>>>> Marcus
>>>>>>
>>>>>> On 07.02.23 06:19, Ron Economos wrote:
>>>>>>> You probably need the development package.
>>>>>>>
>>>>>>> sudo apt-get install libsoapysdr-dev
>>>>>>>
>>>>>>> Ron
>>>>>>>
>>>>>>> On 2/6/23 18:37, aardric wrote:
>>>>>>>> I executed the following steps which I think are consistent with
>>>>>>>> documentation on the wiki.
>>>>>>>>
>>>>>>>> (1) local installation of SoapySDR 0.7.2 appears to work.
>>>>>>>> (2) build and local install of gnuradio 3.10.5.1 works as expected
>>>>>>>> with
>>>>>>>> -DENABLE_GR_SOAPY=OFF
>>>>>>>> (3) delete the gnuradio/build folder and run cmake with
>>>>>>>> -DENABLE_GR_SOAPY=ON configures without an obvious problem.
>>>>>>>> (4) however, make fails with:
>>>>>>>> include/gnuradio/soapy/soapy_types.h:15:10: fatal error:
>>>>>>>> SoapySDR/Types.hpp: No such file or directory
>>>>>>>>       15 | #include <SoapySDR/Types.hpp>
>>>>>>>>
>>>>>>>> I'm hoping to get advice on whether the above procedure was reasonable
>>>>>>>> before I (as a non developer) attempts to reverse engineer and
>>>>>>>> debug the
>>>>>>>> above process. I hesitate to raise an issue for something which may be
>>>>>>>> obvious or a problem with my particular installation.
>>>>>>>>
>>>>>>>> Rick
>>>>>>>>
>>>>>>>>
>>>>>>>>
>

No comments:

Post a Comment