Closed chadmspooner closed 9 years ago
Can you try to change out the URL in recipes/mcpp.lwr to this:
http://prdownloads.sourceforge.net/mcpp/mcpp-2.7.2.tar.gz
Using sourceforge might be more stable for downloading the package.
Why is mcpp used at all?
You're not going to like the answer: ice.
Also, looks like it's a dependency for gnuradio 3.6, though I'm not sure why off the top of my head.
ISTR not needing mcpp when compiling GR manually, 3.6 or 3.7. I was surprised when I saw it in PyBOMBS.
Tom:
I replaced the URL as suggested. Reran pybombs. Much downloading and installing ensued. Eventually this happened:
Running transaction (shutdown inhibited) Installing : ice-python-3.5.1-2.fc20.x86_64 1/2 Installing : ice-python-devel-3.5.1-2.fc20.x86_64 2/2 Verifying : ice-python-3.5.1-2.fc20.x86_64 1/2 Verifying : ice-python-devel-3.5.1-2.fc20.x86_64 2/2
Installed: ice-python-devel.x86_64 0:3.5.1-2.fc20
Dependency Installed: ice-python.x86_64 0:3.5.1-2.fc20
Complete! installation ok via: rpm Installing from source: gnuradio Cloning into 'gnuradio'... Checking connectivity... done. Configuring: (100%) [==========================================================] Configuration failed. Re-trying with higher verbosity. make: *\ No targets specified and no makefile found. Stop. Build failed. See output above for error messages.
I'm installing this on a Fedora 20 computer (3.17.8-200.fc20.x86_64). I've already successfully installed UHD using the Ettus yum repository (and help from Ettus when that failed; had to update the FPGA image).
So that's good about the mcpp issue. We might have to update the recipe for that.
As for the problem with GNU Radio itself, that's very strange to fail like that, and I'm sure there's no specific problem on Fedora 20. Can you rerun the install using the '-v' flag and see what the output says? It should provide you with the actual error during cmake configure.
Here is the tail of the output of pybombs -v install gnuradio:
-- Configuring gr-fcd support... -- Dependency Boost_FOUND = 1 -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Dependency ENABLE_GR_BLOCKS = ON -- Dependency ENABLE_GR_AUDIO = ON -- Dependency LIBUSB_FOUND = FALSE CMake Error at cmake/Modules/GrComponent.cmake:75 (message): user force-enabled gr-fcd but configuration checked failed Call Stack (most recent call first): gr-fcd/CMakeLists.txt:35 (GR_REGISTER_COMPONENT)
-- Configuring incomplete, errors occurred! See also "/home/spooner/pybombs/src/gnuradio/build/CMakeFiles/CMakeOutput.log". See also "/home/spooner/pybombs/src/gnuradio/build/CMakeFiles/CMakeError.log". Configuration failed. Re-trying with higher verbosity. make: *\ No targets specified and no makefile found. Stop. Build failed. See output above for error messages.
Strange, but looks like libusb strikes again. We're constantly seeing problems with that one on all sorts of different platforms.
See what happens when you add 'libusb' to the list of depends in gnuradio.lwr. This might be a result of you installing UHD youself, since uhd.lwr shows a dependency for libusb already.
That seems to have done it. The installer runs to completion! The gnuradio/bin directory is populated. If I have further troubles, I'll open a different Issue.
Thanks very much for the quick help. I really appreciate it.
Chad
All is well; I am able to use uhd_fft and uhd_rx_cfile and get correct data from the Ettus X310.
During install the installer cannot download a file from aptproxy.willowgarage.com:
--2015-01-22 10:01:02-- (try: 4) http://aptproxy.willowgarage.com/archive.ubuntu.com/ubuntu/pool/universe/m/mcpp/mcpp_2.7.2.orig.tar.gz Connecting to aptproxy.willowgarage.com (aptproxy.willowgarage.com)|70.35.54.201|:80... failed: Connection timed out. Retrying.
This goes on for some time (scores of retries) before the installer finally quits.
I've tried to find a way to avoid this search, but I can't figure out where pybombs is storing the name of the aptproxy server. I can download the mcpp_2.7.2_orig.tar.gz from various places on the internet, but I don't know how to modify pybombs to avoid timing out on requests to the aptproxy server.
Does anyone have any suggestions? I tried to find mentions of this problem on this site and on the internet, but found nothing helpful.
Chad