Re: Problems with gr-modtool on Ubuntu 20.04 (gnuradio 3.10.4)

[Ryan Volz]

Hi Michael,

On 10/3/22 1:21 AM, Michael Matthews wrote:

...

-- Found Boost: 
/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found 
suitable version "1.71.0", minimum required is "1.71.0") found 
components: date_time program_options system regex thread 
unit_test_framework


The above line shows where I think things start to go wrong for you. 
Ubuntu links /lib to /usr/lib, and CMake has found at least Boost with 
the /lib prefix.



...

CMake Error in lib/CMakeLists.txt:

   Imported target "gnuradio::gnuradio-runtime" includes non-existent path

     "/include"

   in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

   * The path was deleted, renamed, or moved to another location.

   * An install or uninstall procedure did not complete successfully.

   * The installation package was faulty and references files it does not

   provide.

...


So CMake ends up setting the INTERFACE_INCLUDE_DIRECTORIES for a few 
targets to "/include" (which doesn't exist) when it should be 
"/usr/include". Reading the CMake code, the way it gets this directory 
is by:


1) Finding the directory containing the gnuradio-runtimeTargets.cmake 
file (should be /usr/lib/x86_64-linux-gnu/cmake/gnuradio)
2) Stripping the last 4 directories from that path to get the prefix 
(should be /usr)

3) Then appending "/include" (should be /usr/include)

In your case, I suspect what's happening is 
"/lib/x86_64-linux-gnu/cmake/gnuradio" -> "/" -> "/include" because of 
that /lib to /usr/lib symlink.


The curious thing is, there is CMake code in 
gnuradio-runtimeTargets.cmake that is supposed to handle this exact case 
and replace "/lib/x86_64-linux-gnu/cmake/gnuradio" with 
"/usr/lib/x86_64-linux-gnu/cmake/gnuradio". So why isn't that working, 
or what is different about your system???


I think you can trace what's happening in that file by running cmake 
with 
"--trace-source=/usr/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake", 
so probably


cmake .. 
--trace-source=/usr/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake


Hopefully that provides some illuminating information.

Cheers,
Ryan

RE: Problems with gr-modtool on Ubuntu 20.04 (gnuradio 3.10.4)

[Michael Matthews]

Hey Ryan,



I went ahead and ran that cmake trace and it did produce something interesting. 
 I seems that two cmake policies are not set and both have the behavior to not 
throw warnings by default. The offending policies are:

- CMP0060

- CMP0082



CMP0060 is defined by the cmake documentation as "Link libraries by full path 
even in implicit directories".

CMake does allow projects to override this behavior by using an IMPORTED 
library target with its IMPORTED_LOCATION property set to the desired full path 
to a library file. In fact, many Find Modules are learning to provide Imported 
Targets instead of just the traditional Foo_LIBRARIES variable listing library 
files. However, this makes the link line generated for a library found by a 
Find Module depend on whether it is linked through an imported target or not, 
which is inconsistent. Furthermore, this behavior has been a source of 
confusion because the generated link line for a library file depends on its 
location. It is also problematic for projects trying to link statically because 
flags like -Wl,-Bstatic -lfoo -Wl,-Bdynamic may be used to help the linker 
select libfoo.a instead of libfoo.so but then leak dynamic linking to following 
libraries. (See the LINK_SEARCH_END_STATIC target property for a solution 
typically used for that problem.)

When the special case for libraries in implicit link directories was first 
introduced the list of implicit link directories was simply hard-coded (e.g. 
/lib, /usr/lib, and a few others). Since that time, CMake has learned to detect 
the implicit link directories used by the compiler front-end. If necessary, the 
find_library() command could be taught to use this information to help find 
libraries of the proper architecture.

For these reasons, CMake 3.3 and above prefer to drop the special case and link 
libraries by full path even when they are in implicit link directories. Policy 
CMP0060 provides compatibility for existing projects.

The OLD behavior for this policy is to ask the linker to search for libraries 
whose full paths are known to be in implicit link directories. The NEW behavior 
for this policy is to link libraries by full path even if they are in implicit 
link directories.
CMP0082 is defined by the cmake documentation as “Install rules from 
add_subdirectory() calls are interleaved with those in caller”.

CMake 3.13 and lower ran the install rules from add_subdirectory() after all 
other install rules, even if add_subdirectory() was called before the other 
install rules. CMake 3.14 and above prefer to interleave these 
add_subdirectory() install rules with the others so that they are run in the 
order they are declared. This policy provides compatibility for projects that 
have not been updated to expect the new behavior.

The OLD behavior for this policy is to run the install rules from 
add_subdirectory() after the other install rules. The NEW behavior for this 
policy is to run all install rules in the order they are declared.



My best guess is that CMP0060 is the primary offending issue on my system. I am 
as familiar with cmake policies as I am with other build systems. Would either 
or both need to be explicitly declared in the cmake files? I am running cmake 
3.16.3 which is above the minimum (3.8) in the root CMakeLists.txt. CMP0082 is 
the only policy warning here that was defined after the minimum version.



Thank you for your help,

Michael



PS.

The trace output I received is below:

~/gr-customModule/build$ cmake .. 
--trace-source=/usr/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake

-- The CXX compiler identification is GNU 9.4.0

-- The C compiler identification is GNU 9.4.0

-- Check for working CXX compiler: /usr/bin/c++

-- Check for working CXX compiler: /usr/bin/c++ -- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- Check for working C compiler: /usr/bin/cc

-- Check for working C compiler: /usr/bin/cc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- Looking for pthread.h

-- Looking for pthread.h - found

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed

-- Looking for pthread_create in pthreads

-- Looking for pthread_create in pthreads - not found

-- Looking for pthread_create in pthread

-- Looking for pthread_create in pthread - found

-- Found Threads: TRUE

-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")

-- Checking for module 'gmp'

--   Found gmp, version 6.2.0

-- Found GMP: /usr/lib/x86_64-linux-gnu/libgmpxx.so

-- Using GMP.

-- Found MPLIB: /usr/lib/x86_64-linux-gnu/libgmpxx.so

-- Found Boost: /lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake 
(found suitable version "1.71.0", minimum required is "1.71.0") found 
component

Re: Problems with gr-modtool on Ubuntu 20.04 (gnuradio 3.10.4)

[Cinaed Simson]

Try this

  cd $HOME/gr-customModule
  rm -fr build
  mkdir build
  cd build
  cmake --debug-output .. >& build.log

The first couple of lines should have entries which look something like:

  /usr/share/cmake-3.18/Modules

Also, if you

cd $HOME/gr-customModule/build
  grep ROOT CMakeCache.txt

this will tell you where your cmake ROOT is located.

There are also 2 other log files in

$HOME/gr-customModule/build/CMakeFiles
 CMakeError.log
 CMakeOutput.log

-- Cinaed


On 10/17/22 20:56, Michael Matthews wrote:


Hi Cinaed,

Yes, sorry that was a typo. The flag I have been using is:

-DCMAKE_FIND_ROOT_PATH=/usr  (not =usr/)

Running

cmake ..

from

$HOME/gr-customModule/build

without that flag still results in the error.

I am unsure what you mean by remove CMAKE_FIND_ROOT_PATH, are you 
saying you believe I need to alter my cmake installation for this to 
work without the flag?


Doing some more digging through the wiki, I did find that I could 
check my gnuradio configuration information using 
gnuradio-config-info. If I run


gnuradio-config-info –prefix

I get:

/usr/

If this is related to the cmake root path, it seems to be set 
correctly by default when I installed gnuradio through the ppa.


I also tried upgrading my version of cmake to see if that would help. 
I removed the old version using apt (3.16.3) and installed the one 
managed through snap (3.24.2). This however did not solve the issue.


I am going to try uninstalling gnuradio with apt again, but will build 
gnuradio from source instead, and see if there have been any changes 
that may have fixed this. If not, and if there are no objections, I am 
inclined to submit an issue ticket since there seems to be problems 
with the cmake imported targets


  * gnuradio::gnuradio-runtime
  * Boost::date_time

When building an OOT using gr_modtool on fresh installs of v3.10.4.0 
and Ubuntu 20.04.


Thank you,

Michael Matthews
Graduate Software Engineer
Mobile: +1 847 714 4809


Micro-X 

855 South 192nd St, Suite 600
SeaTac, WA, 98148, United States
*www.micro-x.com *

*From:*Cinaed Simson 
*Sent:* Monday, October 17, 2022 4:41 PM
*To:* Michael Matthews ; GNURadio Discussion 
List 

*Subject:* Re: Problems with gr-modtool on Ubuntu 20.04 (gnuradio 3.10.4)

The cmake flag

-DCMAKE_FIND_ROOT_PATH=usr/

has an incorrect root element - it's root element.

Make sure the CMAKE_FIND_ROOT_PATH defined by you has been removed.

Then start a new build:

  cd $HOME/gr-customModule
   rm -fr build
   mkdir bulid
   cd build
   cmake ..

-- Cinaed

On 10/17/22 11:43, Michael Matthews wrote:

Hi Cinaed,

I took your suggestion of making the customModule with gr-modtool
at the $HOME directory, in case this may be required. The tutorial
implied this was not necessary, but I gave it a shot anyway.
Invoking cmake from

$HOME/gr-customModule/build

as

cmake ..

resulted in no change and the error is still present if I do not
use the flag:

-DCMAKE_FIND_ROOT_PATH=usr/

When you mention there are 9 CMakeLists.txt files in your
directory, I believe those are the same as I listed. Could you
clarify if you have any outside those specific paths I mentioned?

I also wanted to follow up on your suggestion that I should not be
seeing the line
   -- Using install prefix: /usr/local

in my cmake output. It seems that that is printed from
$HOME/gr-customModule/lib/CMakeLists.txt line 47 (in the print
summary section). It prints CMAKE_INSTALL_PREFIX, which is
/usr/local by default on UNIX systems according to cmake
documentation. Could you also clarify what I should be seeing instead?

You also mention that if invoking cmake doesn’t work, it most
likely operator error. Again, I am new to gnuradio and I am unsure
what that error would be. I followed the tutorials verbatim. I am
running gnuradio 3.10.4, cmake 3.16.3, and Ubuntu 20.04.

I have tested this now on two clean VM installs of Ubuntu 20.04
and gnuradio 3.10.4 (through the apt PPA) and am still seeing this
error.

I appreciate the help! Cheers,

Michael Matthews
Graduate Software Engineer
Mobile: +1 847 714 4809



Micro-X



855 South 192nd St, Suite 600
SeaTac, WA, 98148, United States
*www.micro-x.com

Re: Problems with gr-modtool on Ubuntu 20.04 (gnuradio 3.10.4)

[Cinaed Simson]

The warnings are for the developers.

It's clear cmake is working.

In the output of the trace there are 2-3 non-existent paths which appear 
to be related to the absolute path.


  "$HOME/gr-customModule/include/gnuradio/customModule"

If the absolute path gets clipped to "/include/gnuradio/customModule" , 
then


  "/include"

would become an non-existent directory since there is no "/include" 
directory on Linux.


And hence all directories below it would become nonexistent and cmake 
crashes and burns.


It's more likely it could be operator error of  gr-modtool then a 
problem with cmake.


-- Cinaed


On 10/18/22 14:47, Michael Matthews wrote:


Hey Ryan,

I went ahead and ran that cmake trace and it did produce something 
interesting.  I seems that two cmake policies are not set and both 
have the behavior to not throw warnings by default. The offending 
policies are:


- CMP0060

- CMP0082

CMP0060 is defined by the cmake documentation as "Link libraries by 
full path even in implicit directories".


CMake does allow projects to override this behavior by using an 
IMPORTED library target with its IMPORTED_LOCATION property set to the 
desired full path to a library file. In fact, many Find Modules are 
learning to provide Imported Targets instead of just the traditional 
Foo_LIBRARIES variable listing library files. However, this makes the 
link line generated for a library found by a Find Module depend on 
whether it is linked through an imported target or not, which is 
inconsistent. Furthermore, this behavior has been a source of 
confusion because the generated link line for a library file depends 
on its location. It is also problematic for projects trying to link 
statically because flags like -Wl,-Bstatic -lfoo -Wl,-Bdynamic may be 
used to help the linker select libfoo.a instead of libfoo.so but then 
leak dynamic linking to following libraries. (See the 
LINK_SEARCH_END_STATIC target property for a solution typically used 
for that problem.)


When the special case for libraries in implicit link directories was 
first introduced the list of implicit link directories was simply 
hard-coded (e.g. /lib, /usr/lib, and a few others). Since that time, 
CMake has learned to detect the implicit link directories used by the 
compiler front-end. If necessary, the find_library() command could be 
taught to use this information to help find libraries of the proper 
architecture.


For these reasons, CMake 3.3 and above prefer to drop the special case 
and link libraries by full path even when they are in implicit link 
directories. Policy CMP0060 provides compatibility for existing projects.


The OLD behavior for this policy is to ask the linker to search for 
libraries whose full paths are known to be in implicit link 
directories. The NEW behavior for this policy is to link libraries by 
full path even if they are in implicit link directories.


CMP0082 is defined by the cmake documentation as “Install rules from 
add_subdirectory() calls are interleaved with those in caller”.


CMake 3.13 and lower ran the install rules from add_subdirectory() 
after all other install rules, even if add_subdirectory() was called 
before the other install rules. CMake 3.14 and above prefer to 
interleave these add_subdirectory() install rules with the others so 
that they are run in the order they are declared. This policy provides 
compatibility for projects that have not been updated to expect the 
new behavior.


The OLD behavior for this policy is to run the install rules from 
add_subdirectory() after the other install rules. The NEW behavior for 
this policy is to run all install rules in the order they are declared.


My best guess is that CMP0060 is the primary offending issue on my 
system. I am as familiar with cmake policies as I am with other build 
systems. Would either or both need to be explicitly declared in the 
cmake files? I am running cmake 3.16.3 which is above the minimum 
(3.8) in the root CMakeLists.txt. CMP0082 is the only policy warning 
here that was defined after the minimum version.


Thank you for your help,

Michael

PS.

The trace output I received is below:

~/gr-customModule/build$ cmake .. 
--trace-source=/usr/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake


-- The CXX compiler identification is GNU 9.4.0

-- The C compiler identification is GNU 9.4.0

-- Check for working CXX compiler: /usr/bin/c++

-- Check for working CXX compiler: /usr/bin/c++ -- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- Check for working C compiler: /usr/bin/cc

-- Check for working C compiler: /usr/bin/cc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- Looking for pthread.h

-- Looking for pthread.h - found

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD

-- P

System Requirements for High Bandwidth SDRs Based on Your Experience

[Mutlu Aydın]

Hello,

I am searching for a computer/workstation that will work with high
bandwidth SDRs. Do you recommend computer/workstation systems for working
with SDRs that are capable of 200MHz, 400 Mhz, 800 MHz  and 1600 Mhz etc
instantaneous bandwidth based on your experience? What are important specs
(RAM CPU etc)  for receiving without dropping samples?

Thank you.

Mutlu AYDIN