– Configuring VOLK support…-- VOLK submodule is not checked out.–
To check out the VOLK submodule, use:-- git pull
–recurse-submodules=on-- git submodule update-- External VOLK
disabled.-- Override with -DENABLE_INTERNAL_VOLK=ON/OFF-- CMake Error
at
CMakeLists.txt:309 (message): VOLK required but not found.
I’ve run the two git commands it asks me to run, deleted the build
directory and re-ran cmake but I get the same error. I see a volk
directory
in the gnuradio directory.
I’d also like to point out that you should not clone into
/usr/local/bin; that’s the directory where the executables should/will
be installed, but no place for source code!
If you don’t do that but instead clone to, let’s say /home/richard/,
then the only operation you need to do as root (“sudo”) is “make
install”; that’s much better.
Just throwing in my $.02 here to prevent bad habits from forming.
/usr/local/bin is an odd place to store the repository. You should do
the
clone some place that you have write permission so you don’t have to do
it
with sudo. Then when you do the install step it can install to
/usr/local
with sudo.
You probably shouldn’t put code into /usr/local/bin as that is reserved
for
binaries, and you shouldn’t build as root. I clone stuff into
/usr/local/src, so do this:
sudo mkdir /usr/local/src
sudo chmod 777 /usr/local/src
cd /usr/local/src
git clone –recursive https://github.com/gnuradio/gnuradio.git
cd gnuradio
mkdir build
cd build
cmake …/
make
make test
sudo make install
Note the “git clone –recursive” will populate the volk directory.
Lou
I completed the source install of both gnuradio 3.7.8git-0-g24a05ca0 and
uhd. Everything completed with no errors thanks to your help.
Now, when I open a flowgraph that I made previously in git 3.7.8, that
uses
the new “correlation estimator” and “modulate vector” blocks, it tells
me
the block “digital_corr_est_cc” and “modulate_vector” were not found in
Platform. Did these blocks get pulled or is this a sign of something
else
in my install?
On Wed, Jun 10, 2015 at 7:21 PM, Richard B. [email protected]
wrote:
I think I figured out what happened, though I don’t understand it. I
cloned gnuradio, than ran ‘git checkout 3.7.8git’ to switch to 3.7.8. I
than installed from there, however, I needed to then do a pull after the
switch to get a lot of files. I just assumed a new clone would contain
everything. Always learning something new.
Rich
Ah, ok. You probably want to just work off the master branches HEAD,
which
is what you get when you pull down the git repo in the first place.
The way the git tags work in our project is that at the release, we tag
the
version, say v3.7.7. We then update the version information in the tree
and
tag that – one commit later – as the v3.7.8git working branch. So that
is
just the start of the work on the next version but does not represent
any
work done there. It’s pretty much the same code as in 3.7.7 with only
version info changed.
Thanks Tom I understand now. Everything is working again.
One more question about the tags. When I install Master -> HEAD, the
version in GRC (from help->about) is 3.7.7.1. Why is there a tag for
version 3.7.8 in the repo, if its content is behind that of 3.7.7.1?
I think I figured out what happened, though I don’t understand it. I
cloned
gnuradio, than ran ‘git checkout 3.7.8git’ to switch to 3.7.8. I than
installed from there, however, I needed to then do a pull after the
switch
to get a lot of files. I just assumed a new clone would contain
everything.
Always learning something new.
Unfortunately, I have to resurrect this thread. I’m still not able to
get
the version of gnuradio installed that allows me to use control ports.
When
I use the master/head branch, which is the default as Tom said when you
clone the repo, after cmake completes, it tells me this:
– Building for version: v3.7.7.1-154-g7ee2f91d / 3.7.8git
Is the 3.7.7.1-154-xxx what I keep seeing as the version in GRC, while
the
3.7.8git is the version of the underlying source code? If so, is this
what
I should be installing to use control ports and if not, what should I be
checking out before I compile the gnuradio source?
Here is what happens when I run a flowgraph with a ‘CtrlPort Performance
Monitor’ included:
Using Volk machine: avx_64_mmx
ControlPort Monitor running.
Traceback (most recent call last):
File “/home/rbell/Documents/tsv/production/bpsk/sbpsk_loopback.py”,
line
1057, in
(tb.blocks_ctrlport_monitor_performance_0).start()
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/monitor.py”,
line
48, in start
print “monitor::endpoints() = %s” %
(gr.rpcmanager_get().endpoints())
AttributeError: ‘NoneType’ object has no attribute ‘endpoints’
ctrlport.monitor received shutdown signal
Today I uninstalled gnuradio, searched my computer for anything gnuradio
related and removed it (minus some custom blocks that i’ve created that
I
assume won’t mess with an install) and reinstalled uhd and gnuradio from
source. I am fairly certain I don’t have a conflicting versions problem.
Richard, you’re getting the right version. The 3.7.7.1 string is an
artifact of how git describe searches backward for the latest annotated
tag
in order to come up with a description.
On Thu, Jun 11, 2015 at 4:24 PM, Richard B. [email protected]
wrote:
Thanks Tom I understand now. Everything is working again.
One more question about the tags. When I install Master -> HEAD, the
version in GRC (from help->about) is 3.7.7.1. Why is there a tag for
version 3.7.8 in the repo, if its content is behind that of 3.7.7.1?
Rich
Something is wrong there. It should read “3.7.8git-”. You
possibly have two versions installed.
You can see the “gr-ctrlport;* thrift” – which tells you the same info
as
cmake.
One thing, though, I’ve just pushed a couple of fixes for
ControlPort/Thrift support. So when you rebuild, make sure you’re
pulling
down the latest master.
I was overlooking the Thrift dependency previously. I installed Thrift
0.9.2 from source, following this https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort as well
as
the Thrift homepage install instructions, http://thrift.apache.org/docs/install/, because I needed to install a
few
more dependencies for thrift than what was listed in the first link. I
then
deleted build and re-built gnuradio. When I ran CMake, I saw that under
the
gr-ctrlports module section it said it found thrift 0.9.2. Was there
something else I needed to confirm in the cmake output beyond that?
When I run gnuradio-config-info --enabled-components, I see
‘gr-ctrlport’
in the list, but no ‘* thrift’.
What else have I overlooked, that always seems to be the issue.
On Wed, Jun 17, 2015 at 3:09 PM, Richard B. [email protected]
wrote:
I was overlooking the Thrift dependency previously. I installed Thrift
0.9.2 from source, following this https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort as well
as the Thrift homepage install instructions, http://thrift.apache.org/docs/install/, because I needed to install a few
more dependencies for thrift than what was listed in the first link. I then
deleted build and re-built gnuradio. When I ran CMake, I saw that under the
gr-ctrlports module section it said it found thrift 0.9.2. Was there
something else I needed to confirm in the cmake output beyond that?
On Wed, Jun 17, 2015 at 6:09 PM, Richard B. [email protected]
wrote:
something else I needed to confirm in the cmake output beyond that?
When I run gnuradio-config-info --enabled-components, I see ‘gr-ctrlport’
in the list, but no ‘* thrift’.
What else have I overlooked, that always seems to be the issue.
Rich
Probably the installation of the Thrift Python module. Did you set a
different prefix for the installation of Thrift? It likes to try to
stuff
it in /usr/lib/python2.7/site-packages regardless of what you set the
–prefix to. You have to use PY_PREFIX on the configure line for that. A
lesson we just learned yesterday.
Also, because it goes into site-packages instead of dist-packages like
most
distros use these days, that could also be affecting whether or not
Python
is finding it.