this really is, by all symptoms, a problem of how files are installed, not how things are built. Swig works well if the library from the build/swig directory works!
So, I think we moved a bit forward here: since python finds the right __init__.py (if I follow correctly), but fails on loading the .so module itself: Is /usr/local/lib part of the LD_LIBRARY_PATH ? If not, can you add it, and run "sudo ldconfig"?
I can see it makes no sense that adding lines to the init.py telling it to look in the build directories fixes the problem and it’s probably not a viable long
I will continue investigating.
However, ‘it’ (python, the GRC) does go to the install tree i.e., to the /usr/local/lib/python2.7/site-packages (I’ve fixed the PATH variables now permanently
in the shell) to get __init__.py because if I change it in the gr-howto/python directory I have to re-make and reinstall to break it again or fix it again.
Also some testing has shown it is a “swig” problem. The init.py throws the exception at the ‘from howto_swig import *’ line unless the sys.path append of the
/build/swig directories is present. You actually don’t need the other two append lines to get it to work.
On 02/09/2017 05:07 PM, Jacqueline.Walker wrote:
According to the build/install_manifest.txt it installs to:
And various other /usr/local/ paths as appropriate e.g. /usr/local/include/ /usr/local/share/
Does that make sense?
I followed the instructions – exactly – to use gr_modtool to create a module, then add a block… I make a build directory and use the cmake, then make then sudo
make install commands as per instructions…
When I had not updated the pythonpath to include the install location I got the import error. After that was fixed I get the attribute error of this kind:
Traceback (most recent call last):
File "square_floats.py", line 159, in <module>
File "square_floats.py", line 147, in main
tb = top_block_cls()
File "square_floats.py", line 113, in __init
self.howto_square2_ff_0 = howto.square2_ff()
AttributeError: 'module' object has no attribute ‘square_ff’
which is only fixed by the aforementioned kludge.
Investigating this showed that it is going to the installed module in the pythonpath – it’s only when I successfully alter that that it works!!
I think the problem is that python looks into /usr/lib/python2.7/..., but not into /usr/local/lib/python2.7/site-packages/ ; maybe you'd want
to add that to the pythonpath?
You can alternatively use "cmake -DCMAKE_INSTALL_PREFIX=/usr .." to explicitly install into /usr/lib/python2.7/site-packages, but that is probably against all rules of Arch.
If said file only has for example:
from howto_swig import *
then it will not work but will throw the attribute error.
hm, I see! But where *did* you then install your gr-tutorial to, then (if in doubt, look into build/install_manifest.txt)? Point is that the *installation target* should be part of your python path, not the source (/python) nor the build (/build) directories.
On 02/09/2017 04:48 PM, Jacqueline.Walker wrote:
I know it’s a kludge but I’ve been working on this steadily when I can to try and work out why it hasn’t been working despite following all directions in the
tutorials, and so far this is the only way to get it to work.
It’s how I got the python and C++ blocks in the Guided Tutorials to work and then I tried again with the square_ff() OOT modules tutorial thinking it must have
been something I did wrong. I fixed a few other issues I had via that route (I had ‘orphan’ modules in the GRC) but I still had these runtime errors when I tried to run the ‘howto’ blocks.
I didn’t use pybombs to install – I haven’t touched pybombs. As I’m on Arch, I installed everything from the Archlinux packages using pacman.
Since I’ve been going through this second sequence of tutorials I’ve had no problems and no error messages with make and make install! So there’s no hint it’s
not going to work until runtime.
I did get an ImportError initially but I fixed that by setting the PYTHONPATH properly.
that is not a fix I'd recommend – if this is really just all it takes to get your module running, than plainly, something has gone wrong with installing the gr-tutorial module. Did "make install" work well? Where did things get installed to? Is that installation
target right inside your pybombs prefix?
On 02/09/2017 04:27 PM, Jacqueline.Walker wrote:
Hi Tellrell and others,
I have been having similar problems while going through the various tutorials and have come up with some workarounds (with help from a python expert – my 21
year old son) and am now getting to the bottom of it.
I have fixed it by adding the following lines to the -_init__.py file and then re-doing the make and make install steps so that it gets compiled into the site-packages
directories in the PYTHONPATH.
I suppose I could add these paths to the sys path and that would fix the problem once and for all.
From: Discuss-gnuradio [mailto:discuss-gnuradio-bounces+address@hidden]
On Behalf Of Ben Hilburn
Sent: 09 February 2017 15:14
To: Tellrell White
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Gr-Inspector Install error
Hi Tellrell -
It looks like your `gr-inspector` OOT module isn't getting found by GNU Radio. How did you install it? Are you using PyBOMBS? Are you sure you installed it into the same directory as GNU Radio?
On Tue, Feb 7, 2017 at 3:51 PM, Tellrell White <address@hidden> wrote:
I'm running the live_signal_detection. I replaced the rtlsdr_source block with a signal source block. When I run the flowgraph I get
"attributerror: Module object has no attribute 'signal_detector_cvf"
I tried deleting and reinstalling all the dependencies before installing gr-inspector but I'm getting the same result.
On Tuesday, February 7, 2017 7:53 AM, Christopher Richardson <address@hidden>
Discuss-gnuradio mailing list
Discuss-gnuradio mailing list