Now I understand the environment variable issue. Would it make more sense just
to do a "make install" then see what fails on "make test"? Or will make test
always use shall we say a custom environment?
The rest of the suggestions I will need to chew on later when on the PC.
Original Message
From: Michael Dickens
Sent: Wednesday, May 24, 2017 6:53 AM
To: li...@lazygranch.com; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] GSL Gnu Scientific Library 2.3
1) You should do "su" or "sudo" as you see fit. Either way works.
2) The way CMake does testing is that it creates a shell script, which
sets environment variables for just whatever is being executed for that
specific test. These variables are configured in the GR build scripts
via GrTest & variables it makes use of; they are supposed to point to
the internal GR build where libraries ands scripts are located, so that
those are used instead of any already-installed ones. Thus one can edit
the test shell script & tweak just those environment variables to change
what's going on with any specific test, without CMake complaining.
As an example, when I build GR & it's not installed then "ctest -V -R
qa_polar_encoder_systematic" fails for me with the error (I've replaced
the /path/to/ with just "...." since it's easier to read & is more
generic):
{{{
97: ImportError: dlopen(..../build/gr-blocks/swig/_blocks_swig0.so, 2):
Library not loaded: /opt/local/lib/libgnuradio-blocks.3.7.11.dylib
97: Referenced from: ..../build/gr-blocks/swig/_blocks_swig0.so
97: Reason: image not found
}}}
which indicates that the GrTest configuration for that test is missing
"gr-blocks" (or whatever it is called internal to the GR build) ...
meaning the path to the library libgnuradio-blocks.
So, if I edit the shell script
"..../build/gr-fec/python/fec/qa_polar_encoder_systematic_test.sh" &
augment the LD*_LIBRARY_PATH to include "..../build/gr-blocks/lib", then
the ctest command works.
3) In your case, it looks like the initial "from gnuradio import gr" is
failing, but we don't know why.
The easiest way to find out is to edit the file (in your case)
"/usr/local/src/gnuradio_test/gnuradio/gnuradio-runtime/python/gnuradio/gr/__init__.py"
such that the obvious section reads:
{{{
if _swig_python_version_info >= (2, 7, 0):
def swig_import_helper():
import importlib
pkg = __name__.rpartition('.')[0]
mname = '.'.join((pkg, '_runtime_swig')).lstrip('.')
return importlib.import_module(mname)
_runtime_swig = swig_import_helper()
del swig_import_helper
}}}
Then, try the "ctest ..." command again & it should print the actual
import error ... probably some dependent library is missing or some
symbol isn't defined.
I hope this makes sense. Ask more if not. - MLD
On Wed, May 24, 2017, at 09:26 AM, li...@lazygranch.com wrote:
> I'm not sure I follow you here on the environment variables. They have to
> be proper for both normal and tests operation.
>
> Regarding sudo, when I am working in /usr/local, I just do su and be done
> with it.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
