discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Cinaed Simson
Subject: Re: Problems with gr-modtool on Ubuntu 20.04 (gnuradio 3.10.4)
Date: Tue, 18 Oct 2022 20:41:21 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2

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

-- 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 components: date_time program_options system regex thread unit_test_framework

-- Found Volk: Volk::volk 

-- User set python executable /usr/bin/python3

-- Found PythonInterp: /usr/bin/python3 (found version "3.8.10")

-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so (found suitable exact version "3.8.10")

-- Check if the system is big endian

-- Searching 16 bit integer

-- Looking for sys/types.h

-- Looking for sys/types.h - found

-- Looking for stdint.h

-- Looking for stdint.h - found

-- Looking for stddef.h

-- Looking for stddef.h - found

-- Check size of unsigned short

-- Check size of unsigned short - done

-- Using unsigned short

-- Check if the system is big endian - little endian

-- Performing Test HAVE_VISIBILITY_HIDDEN

-- Performing Test HAVE_VISIBILITY_HIDDEN - Success

-- Performing Test HAVE_WARN_SIGN_COMPARE

-- Performing Test HAVE_WARN_SIGN_COMPARE - Success

-- Performing Test HAVE_WARN_ALL

-- Performing Test HAVE_WARN_ALL - Success

-- Performing Test HAVE_WARN_NO_UNINITIALIZED

-- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success

-- Found Git: /usr/bin/git 

-- Found Doxygen: /usr/bin/doxygen (found version "1.8.17") found components: doxygen missing components: dot

-- Using install prefix: /usr/local

-- Building for version: 1.0.0.0 / 1.0.0

-- No C++ unit tests... skipping

-- PYTHON and GRC components are enabled

-- Python checking for pygccxml - found

-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so

-- Performing Test HAS_FLTO

-- Performing Test HAS_FLTO - Success

-- LTO enabled

-- Configuring done

CMake Warning (dev) in CMakeLists.txt:

  Policy CMP0082 is not set: Install rules from add_subdirectory() are

  interleaved with those in caller.  Run "cmake --help-policy CMP0082" for

  policy details.  Use the cmake_policy command to set the policy and

  suppress this warning.

 

This warning is for project developers.  Use -Wno-dev to suppress it.

 

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.

 

 

 

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.

 

 

 

CMake Warning (dev) in python/customModule/CMakeLists.txt:

  Policy CMP0082 is not set: Install rules from add_subdirectory() are

  interleaved with those in caller.  Run "cmake --help-policy CMP0082" for

  policy details.  Use the cmake_policy command to set the policy and

  suppress this warning.

 

This warning is for project developers.  Use -Wno-dev to suppress it.

 

CMake Error in python/customModule/bindings/CMakeLists.txt:

  Imported target "Boost::date_time" 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.

 

 

 

CMake Warning (dev) at /lib/cmake/pybind11/pybind11Tools.cmake:131 (add_library):

  Policy CMP0060 is not set: Link libraries by full path even in implicit

  directories.  Run "cmake --help-policy CMP0060" for policy details.  Use

  the cmake_policy command to set the policy and suppress this warning.

 

  Some library files are in directories implicitly searched by the linker

  when invoked for CXX:

 

   /usr/lib/x86_64-linux-gnu/libgmp.so

   /usr/lib/x86_64-linux-gnu/libgmpxx.so

 

  For compatibility with older versions of CMake, the generated link line

  will ask the linker to search for these by library name.

Call Stack (most recent call first):

  /lib/x86_64-linux-gnu/cmake/gnuradio/GrPybind.cmake:288 (pybind11_add_module)

  python/customModule/bindings/CMakeLists.txt:34 (GR_PYBIND_MAKE_OOT)

This warning is for project developers.  Use -Wno-dev to suppress it.

 

CMake Error in python/customModule/bindings/CMakeLists.txt:

  Imported target "Boost::date_time" 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.

 

 

 

-- Generating done

CMake Generate step failed.  Build files cannot be regenerated correctly.

 

 

 

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

> -----Original Message-----

> From: Ryan Volz <ryan.volz@gmail.com>

> Sent: Tuesday, October 18, 2022 10:06 AM

> To: Michael Matthews <mmatthews@micro-x.com>; discuss-

> gnuradio@gnu.org

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

>

> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]