discuss-gnuradio
[Top][All Lists]
Advanced

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

RE: Discuss-gnuradio Digest, Vol 222, Issue 7


From: edward.kenworthy
Subject: RE: Discuss-gnuradio Digest, Vol 222, Issue 7
Date: Tue, 6 Apr 2021 17:14:20 +0100

unsubscribe

-----Original Message-----
From: Discuss-gnuradio 
<discuss-gnuradio-bounces+edward.kenworthy=me.com@gnu.org> On Behalf Of 
discuss-gnuradio-request@gnu.org
Sent: 06 April 2021 17:00
To: discuss-gnuradio@gnu.org
Subject: Discuss-gnuradio Digest, Vol 222, Issue 7

Send Discuss-gnuradio mailing list submissions to
        discuss-gnuradio@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
        discuss-gnuradio-request@gnu.org

You can reach the person managing the list at
        discuss-gnuradio-owner@gnu.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Discuss-gnuradio digest..."


Today's Topics:

   1. Re: C++ Boost QA-tests linking issues (David Myers)
   2. Re: Upgrade to GNURadio v3.8 Python Issue? (Cinaed Simson)


----------------------------------------------------------------------

Message: 1
Date: Mon, 5 Apr 2021 14:23:50 -0400
From: David Myers <chalkedhands@gmail.com>
To: discuss-gnuradio@gnu.org
Subject: Re: C++ Boost QA-tests linking issues
Message-ID:
        <CAChJu2rfY+g9nSNoPtgb3ZNMCvE=Q-966JaP1xioY4MN2RHEng@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Solved!

The issue was the location of my header file for the class under test 
(Related_Clocks); it was inside the lib/ directory instead of the 
include/OOTM_NAME/ directory.

The class was able to compile when both the .cc and the .h file were located in 
the lib/ directory. However, for CMake to perform the correct linking during 
"make", the header file needs to be located in include/OOTM_NAME/ (along with 
the public api header files for the OOTM blocks). The class declaration also 
needs to include the OOTM_MODULE_API prefix as shown below:

>From gr-time_triggers/include/time_triggers/Related_Clocks.h:

#include <time_triggers/api.h>
namespace gr {
    namespace  time_triggers {
        class TIME_TRIGGERS_API Related_Clocks { [...]

-David Myers

On Fri, Apr 2, 2021 at 1:09 PM David Myers <chalkedhands@gmail.com> wrote:

> Hello all,
>
>
>
> Longtime GNU Radio user, new member to the list here.
>
>
>
> I can’t get any C++ (Boost) QA tests to run in my OOTM. Specifically, 
> I'm running into this linking error during the "make" step.
>
>
>
> usr/bin/ld:
> CMakeFiles/time_triggers_qa_Related_Clocks.cc.dir/qa_Related_Clocks.cc.o:
> in function `test_add1::test_method()': qa_Related_Clocks.cc:(.text+0x4d):
> undefined reference to `gr::time_triggers::Related_Clocks::Related_Clocks()'
>
>
>
> I'm running GNU Radio 3.8.1.0 as installed from Ubuntu 20.04 apt-get. 
> The class being tested (Related_Clocks) has no issues 
> compiling/linking/installing when used in blocks.
>
>
>
> I’ve really been beating my head against this one, and any guidance 
> would be greatly appreciated!
>
> Thank you!
>
> From lib/CMakeLists.txt
>
> --------------------------------------
>
> ######################################################################
> ##
> # Setup library
> ######################################################################
> ##
> include(GrPlatform) #define LIB_SUFFIX
>
> list(APPEND time_triggers_sources
>     Related_Clocks.cc
>     multi_response_1_impl.cc
> )
>
> [...............]
>
> ######################################################################
> ##
> # Build and register unit test
> ######################################################################
> ##
> include(GrTest)
> list(APPEND test_time_triggers_sources
>     qa_Related_Clocks.cc
> )
> list(APPEND GR_TEST_TARGET_DEPS gnuradio-time_triggers) 
> foreach(qa_file ${test_time_triggers_sources})
>     GR_ADD_CPP_TEST("time_triggers_${qa_file}"
>         ${CMAKE_CURRENT_SOURCE_DIR}/${qa_file}
>     )
> endforeach(qa_file)
>
> From qa_Related_Clocks.cc:
>
> -----------------------------------------
>
> #ifdef HAVE_CONFIG_H
> #include <config.h>
> #endif
>
> #include <gnuradio/attributes.h>
> #include <stdio.h>
> #include <boost/test/unit_test.hpp>
> #include "Related_Clocks.h"
>
> BOOST_AUTO_TEST_CASE(test_add1)
> {
>     gr::time_triggers::Related_Clocks clk;
>     clk.add_clock("clk1", (uint64_t)0);
>     clk.add_clock("clk2", (uint64_t)1);
>     clk.set_time("clk1", (uint64_t)10);
>     BOOST_REQUIRE_EQUAL(11, clk.get_time("clk2")); }
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20210405/2c6cc2a7/attachment.html>

------------------------------

Message: 2
Date: Mon, 5 Apr 2021 22:16:57 -0700
From: Cinaed Simson <cinaed.simson@gmail.com>
To: discuss-gnuradio@gnu.org
Subject: Re: Upgrade to GNURadio v3.8 Python Issue?
Message-ID: <6ac40217-6567-cf8a-c4b5-429f8a92f981@gmail.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"


Hi Jeff - I can run the zeromq_pushpull.grcvfrom gnuradio3.8 examples 
without any warnings using version 3.8.2.0-73-g4a84443c, Python 3.7.3 
under Debian 10 (or buster.)

The gnuradio-3.8 install was a clean install.

-- Cinaed


I can run  zmpq

On 4/5/21 4:04 AM, Jeff S wrote:
> I hope this is the correct list for this question.
>
> I'm finally getting around to getting some PCs upgraded from 3.7 to 
> 3.8.  I did the installs to a local prefix and everything seems to be 
> running.  What I'm seeing, however, is when I have a ZMQ Pull Source 
> added to my graph (picture of the simple graph attached), I'm getting 
> some startup warnings a whole bunch of:
>
>
>     $ gnuradio-companion
>     <<< Welcome to GNU Radio Companion v3.8.2.0-88-g38f5ab7b >>>
>
>     Block paths:
>     /home/sdr/sdr/x310/installs/share/gnuradio/grc/blocks
>
>     *Loading: "/home/sdr/jas/flow/untitled.grc"*
>     */usr/lib/python3.6/importlib/_bootstrap.py:219: ImportWarning:
>     can't resolve package from __spec__ or __package__, falling back
>     on __name__ and __path__*
>     *  return f(*args, **kwds)*
>
>
> I've searched the GNURadio Archives for "ImportWarning" to see what 
> could be the issue and it doesn't seems to show up much.  I've checked 
> my PYTHONPATH and LD_LOAD_PATH and I think they seem right (unless I'm 
> not seeing the obvious):
>
>     $ echo $PYTHONPATH
>     
> /home/sdr/sdr/x310/installs/lib/python3/dist-packages:/home/sdr/sdr/x310/installs/lib/python3.6/site-packages:/usr/local/lib/python3/dist-packages:usr/local/lib/python2.7/site-packages:
>     $ echo $LD_LIBRARY_PATH
>     /home/sdr/sdr/x310/installs/lib:/user/local/lib:
>     $ gnuradio-config-info --prefix
>     /home/sdr/sdr/x310/installs
>     $ find /home/sdr/sdr/x310/installs -name gnuradio | grep "packages"
>     /home/sdr/sdr/x310/installs/lib/python3/dist-*packages*/gnuradio
>
>
> Anyone see the obvious thing that I'm missing?
>
> Thanks and regards,
> Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20210405/e2ee2095/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


------------------------------

End of Discuss-gnuradio Digest, Vol 222, Issue 7
************************************************




reply via email to

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