[Discuss-gnuradio] Some problems with library path when running test and proposed fix

[Volker Schroer]

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

0001-Fixing-problems-with-library-path.patch
Description: Text Data