[Discuss-gnuradio] Some problems with library path when running test and proposed fix
In brief: Depending on the settings make test does not always test what
should test.
In detail:
The following is based on gnuradio v3.7.2.1-159-g3fa56a46 though the
problems already exist with older versions.
If I run make test on a fresh build ( but not installed! ) version of
gnuradio I get a lot of errors.
Mainly symbol not found.
This depends on my special ( but I think not really unusual ) setup.
I work with multiple version of gnuradio all installed in /usr/local,
for example:
drwxr-xr-x 9 root root 88 21. Jan 17:27 /usr/local/gnuradio-3.7.1
drwxr-xr-x 9 root root 88 13. Sep 12:13 /usr/local/gnuradio-3.7-debug
The installation to use is selected by an symbolic link:
lrwxrwxrwx 1 root root 14 26. Jan 12:30 /usr/local/gnuradio ->
gnuradio-3.7.1
The gnuradio-libs a referenced by:
LD_LIBRARY_PATH=/usr/local/gnuradio/lib
and
PYTHONPATH=/usr/local/gnuradio/lib64/python2.7/site-packages/
Switching between versions is easy, I've just change the symbolic link.
This works very well.
Installing a new(er) version of gnuradio is as follow.
Clone the repository.
Run cmake in the build- directory defining a new installation directory
and run
make test.
Only if the test are O.K. I'd really like to install the new version.
No the problems arise:
As LD_LIBRARY_PATH is set, the volk test uses the wrong library:
ldd lib/test_all
linux-vdso.so.1 (0x7fff45bff000)
libvolk.so.0.0.0 => /usr/local/gnuradio/lib/libvolk.so.0.0.0
(0x7eff7c501000)
libboost_filesystem.so.1.55.0 =>
/usr/lib64/libboost_filesystem.so.1.55.0 (0x7eff7c2e9000)
libboost_system.so.1.55.0 => /usr/lib64/libboost_system.so.1.55.0
(0x7eff7c0e5000)
libboost_unit_test_framework.so.1.55.0 =>
/usr/lib64/libboost_unit_test_framework.so.1.55.0 (0x7eff7be39000)
libboost_program_options.so.1.55.0 =>
/usr/lib64/libboost_program_options.so.1.55.0 (0x7eff7bbc6000)
libdl.so.2 => /lib64/libdl.so.2 (0x7eff7b9c2000)
liborc-0.4.so.0 => /usr/lib64/liborc-0.4.so.0 (0x7eff7b73b000)
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libstdc++.so.6
(0x7eff7b433000)
libm.so.6 => /lib64/libm.so.6 (0x7eff7b133000)
libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1
(0x7eff7af1c000)
libc.so.6 => /lib64/libc.so.6 (0x7eff7ab6c000)
librt.so.1 => /lib64/librt.so.1 (0x7eff7a964000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7eff7a747000)
/lib64/ld-linux-x86-64.so.2 (0x7eff7c81b000)
So the test results in:
lib/test_all: symbol lookup error: lib/test_all: undefined symbol:
volk_32f_invsqrt_32f_get_func_desc
This can be avoided be adding . to the LD_LIBRARY_PATH in the test script.
Similar problems arise in many tests that depend on the volk library.
For example the analog/qa_agc.py test results in
undefined symbol: volk_malloc
If you have a look into the test script you'll find
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH
export
PYTHONPATH=/home/schroer/gnuradiocomponents/gnuradio/build-master/gnuradio-runtime/python:$PYTHONPATH
The setting of the LD_LIBRARY_PATH makes no real sense. It should be
prefixed with the path to the newly compiled volk library in the build
directory, similarly like the PYTHONPATH is set.
For example:
export
LD_LIBRARY_PATH=/home/schroer/gnuradiocomponents/gnuradio/build-master/volk/lib:$LD_LIBRARY_PATH
There are some other tests affected.
The attached patch adresses these problems and the patch for
FindQwt.cmake solves a problem on gentoo that the wrong qwt library is
used. The original FindQwt.cmake finds the include file of qwt6 but the
lib of qwt5.
-- Volker
>From 3c614ce18ec863eaff3a304c0f1c94c3c730477f Mon Sep 17 00:00:00 2001
From: dl1ksv
Date: Sun, 26 Jan 2014 12:19:31 +0100
Subject: [PATCH] Fixing problems with library path
---
cmake/Modules/FindQwt.cmake| 4 ++--
gr-analog/python/analog/CMakeLists.txt | 2 +-
gr-atsc/python/atsc/CMakeLists.txt | 2 +-
gr-channels/python/channels/CMakeLists.txt | 2 +-
gr-digital/python/digital/CMakeLists.txt | 2 +-
gr-filter/python/filter/CMakeLists.txt | 3 ++-
gr-pager/python/pager/CMakeLists.txt | 2 +-
gr-qtgui/python/qtgui/CMakeLists.txt | 3 ++-
gr-trellis/python/trellis/CMakeLists.txt | 2 +-
gr-vocoder/python/vocoder/CMakeLists.txt | 2 +-
gr-wavelet/python/wavelet/CMakeLists.txt | 2 +-
volk/lib/CMakeLists.txt| 3 ++-
12 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/cmake/Modules/FindQwt.cmake b/cmake/Modules/FindQwt.cmake
index a940558..0e2c135 100644
--- a/cmake/Modules/FindQwt.cmake
+++ b/cmake/Modules/FindQwt.cmake
@@ -21,7 +21,7 @@ find_path(QWT_INCLUDE_DIRS
)
find_library (QWT_LIBRARIES
- NAMES qwt qwt6 qwt-qt4
+ NAMES qwt6 qwt qwt-qt4
HINTS
${CMAKE_INSTALL_PREFIX}/lib
${CMAKE_INSTALL_PREFIX}/lib64
@@ -56,4 +56,4 @@ if(QWT_FOUND)
include ( FindPackageHandleStandardArgs )
find_pac
[Discuss-gnuradio] how to program selector block
Hello every buddy i am working on cognitive radio spectrum sensing . i need a selector block of 1024 fft size fft output . but GRc sector block can be visible up 29 port only . so, how can be make it possible through programming a block to select all 1024 fft and make one out put to find massage 2 of that . please gide me the possible way or logic to program and the steps for signla processing block programming. thanking you -- *Thanks and regard:* *MR.Maheshkumar Pandit* *call @ 9662784649* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Some problems with library path when running test and proposed fix
On Jan 26, 2014, at 11:23 AM, Volker Schroer wrote: > In brief: Depending on the settings make test does not always test what > should test. Hi Volker - If GNU Radio is already installed into the PREFIX provided to cmake during configuration, then during "make test" some of the already-installed libraries will be found and used instead of those just build. This condition can lead to some interesting "make test" errors! I can say with confidence that the -built- libraries are all OK (I've checked both the CMakeLists.txt files as well as used ldd or otool to see what linkage is actually there; it's all good), it's just those found for -testing- which can get mixed up. This is a known problem for a while now (to me), and in my queue to work on sooner or later. I believe that the issue is more extensive than just adding VOLK to the library dependency list for each component. I encounter this in MacPorts because, generally, the GNU Radio port is already installed when an update comes along. The nice part is that it's trivial to replicate in MacPorts, and thus easy to see what needs to be fixed; and, the "how" part isn't too difficult either, just takes perseverance and time. Thanks for the information and patch! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] (no subject)
Hi Maheshkumar, you are missing the Python ZMQ bindings. Please install these, they should usually be available from your linux distribution package repository. Greetings, Marcus On 01/26/2014 07:45 AM, Maheshkumar Pandit wrote: hello sir here , i try to install air modes but i face this kind of error mahesh@HP:~/gr-air-modes/build$ cmake .. -- Build type not specified: defaulting to release. Checking for GNU Radio Module: RUNTIME * INCLUDES=/usr/local/include * LIBS=/usr/local/lib/libgnuradio-runtime.so GNURADIO_RUNTIME_FOUND = TRUE -- -- Python checking for PyZMQ -- Python checking for PyZMQ - not found CMake Error at CMakeLists.txt:87 (message): Python ZMQ bindings not found. please guide me if you face such kind of error thank you -- *Thanks and regard:* * * * MR.Maheshkumar Pandit ** * *call @ 9662784649 * ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to program selector block
Hi Maheshkumar, I don't quite understand you completely. What is your input? Is it vectors of size 1024? Do you need to select complete vectors, or do you need to select elements of these vectors? What has this to do with messages? What messages of 2? Greetings, Marcus On 01/26/2014 06:54 PM, Maheshkumar Pandit wrote: Hello every buddy i am working on cognitive radio spectrum sensing . i need a selector block of 1024 fft size fft output . but GRc sector block can be visible up 29 port only . so, how can be make it possible through programming a block to select all 1024 fft and make one out put to find massage 2 of that . please gide me the possible way or logic to program and the steps for signla processing block programming. thanking you -- *Thanks and regard:* * * * MR.Maheshkumar Pandit ** * *call @ 9662784649 * ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Need an "indicator" on the GUI display
Hi Jim, you can easily code your own GUI ;). Actually, I find that streaming values via UDP or TCP to a remote python application works rather nicely. And I find that gygtk and pycairo are rather powerful toolsets. Also I fiddled around with different python web frameworks, taking data from a socket, and "rendering" it by updating a browser page using ajax, but I kind of lost interest on the way... But maybe this might be of interest to your application case. Greetings, Marcus On 01/25/2014 09:34 PM, j...@moudy.com wrote: I've written an application for my client. The application works great (monitoring multiple channels for radio traffic and recording the demod FM stream). The client would like to see a couple of lights that show activity on the channel rather than a FFT GUI plot, which I like. Does anyone know of a "indicator" (on off light) that I can put on a GUI? Alternatively, maybe a VU meter widget? The Indicator would show when a squelch is active or a threshold has been crossed. Thanks for any ideas. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Need an "indicator" on the GUI display
On 01/26/2014 05:34 PM, Marcus Müller wrote: Hi Jim, you can easily code your own GUI ;). Actually, I find that streaming values via UDP or TCP to a remote python application works rather nicely. And I find that gygtk and pycairo are rather powerful toolsets. Also I fiddled around with different python web frameworks, taking data from a socket, and "rendering" it by updating a browser page using ajax, but I kind of lost interest on the way... But maybe this might be of interest to your application case. Greetings, Marcus O YOu can stick a PROBE in the path, and have a static-text box take the output of a variable that tells you whether threshold exceeded or not. It's not a "lamp", but it does the job. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Some problems with library path when running test and proposed fix
Hi Michael, just for clarification: My CMAKE_INSTALL_PREFIX points to a non existing directory at build and test time. The libraries used depend on the LD_LIBRARY_PATH settings that point to an existing installation. In my case, I can avoid the problems by unsetting the LD_LIBRARY_PATH. It seems that in such a case the libs in the build directory are found. But I suppose that this could not be a general solution as in some cases other important libraries like boost may be found be means of the LD_LIBRARY_PATH. I agree that my patch is not a general solution for this problem, but only a starting point. A general solution could be to prepend the required test libraries to the LD_LIBRARY_PATH as I did it in my patch for the volk lib. -- Volker Am 26.01.2014 23:15, schrieb Michael Dickens: On Jan 26, 2014, at 11:23 AM, Volker Schroer wrote: In brief: Depending on the settings make test does not always test what should test. Hi Volker - If GNU Radio is already installed into the PREFIX provided to cmake during configuration, then during "make test" some of the already-installed libraries will be found and used instead of those just build. This condition can lead to some interesting "make test" errors! I can say with confidence that the -built- libraries are all OK (I've checked both the CMakeLists.txt files as well as used ldd or otool to see what linkage is actually there; it's all good), it's just those found for -testing- which can get mixed up. This is a known problem for a while now (to me), and in my queue to work on sooner or later. I believe that the issue is more extensive than just adding VOLK to the library dependency list for each component. I encounter this in MacPorts because, generally, the GNU Radio port is already installed when an update comes along. The nice part is that it's trivial to replicate in MacPorts, and thus easy to see what needs to be fixed; and, the "how" part isn't too difficult either, just takes perseverance and time. Thanks for the information and patch! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help about using gr-air-modes
Hi, I am using gr-air-modes for decoding the air plane signal with USRP. I've successfully used the "modes_rx" and "modes_gui" for decoding the mode-S packets. However, it seems that the modes_rx or modes_gui can't provide the timestamp of the mode-S packets being decoded. Is there any option that I can set to timestamp the mode-S packet? The reason I want this timestamp function is that I want to know the decoded packet data correspond to which part of the raw data (complex baseband data samples). Thank you for any help you can provide in this situation. I found that there's a file called "air_modes_preamble.cc" seems to provide the timestamp function. Does anyone know how to use this file separately? Best regards, Cheng Chi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help about using gr-air-modes
On Sun, Jan 26, 2014 at 11:48 PM, Cheng Chi wrote: > Hi, > > I am using gr-air-modes for decoding the air plane signal with USRP. I've > successfully used the "modes_rx" and "modes_gui" for decoding the mode-S > packets. > > However, it seems that the modes_rx or modes_gui can't provide the > timestamp of the mode-S packets being decoded. Is there any option that I > can set to timestamp the mode-S packet? The reason I want this timestamp > function is that I want to know the decoded packet data correspond to which > part of the raw data (complex baseband data samples). > If you're using a USRP, you should be getting a timestamp. It's the second number printed, as in the following: (-14 *1.29258827811*) Type 0 (short A-A surveillance) from ab2984 at 3000ft If you are using a GPSDO with your USRP, the printed time will be in UTC seconds. Otherwise, it will be in seconds since the application started running. --n > > Thank you for any help you can provide in this situation. > > I found that there's a file called "air_modes_preamble.cc" seems to > provide the timestamp function. Does anyone know how to use this file > separately? > > Best regards, > Cheng Chi > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
