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 (0x00007fff45bff000)
libvolk.so.0.0.0 => /usr/local/gnuradio/lib/libvolk.so.0.0.0
(0x00007eff7c501000)
libboost_filesystem.so.1.55.0 =>
/usr/lib64/libboost_filesystem.so.1.55.0 (0x00007eff7c2e9000)
libboost_system.so.1.55.0 => /usr/lib64/libboost_system.so.1.55.0
(0x00007eff7c0e5000)
libboost_unit_test_framework.so.1.55.0 =>
/usr/lib64/libboost_unit_test_framework.so.1.55.0 (0x00007eff7be39000)
libboost_program_options.so.1.55.0 =>
/usr/lib64/libboost_program_options.so.1.55.0 (0x00007eff7bbc6000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007eff7b9c2000)
liborc-0.4.so.0 => /usr/lib64/liborc-0.4.so.0 (0x00007eff7b73b000)
libstdc++.so.6 =>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libstdc++.so.6
(0x00007eff7b433000)
libm.so.6 => /lib64/libm.so.6 (0x00007eff7b133000)
libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1
(0x00007eff7af1c000)
libc.so.6 => /lib64/libc.so.6 (0x00007eff7ab6c000)
librt.so.1 => /lib64/librt.so.1 (0x00007eff7a964000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007eff7a747000)
/lib64/ld-linux-x86-64.so.2 (0x00007eff7c81b000)
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