discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Pybombs 2.0 woes


From: Dan CaJacob
Subject: Re: [Discuss-gnuradio] Pybombs 2.0 woes
Date: Sat, 05 Mar 2016 19:11:48 +0000

I had the same pip error.  It seemed to be related to a conflicting version of requests.  I am running Ubuntu 15.10  to fix the problem, I uninstalled my pip-installed pybombs and apt-installed python-pip.  I then installed pip and requests via easy_install (generally don't go this route, but it worked).  Then I was able to install pybombs via pip again and this time build was completely successful.

On Sat, Mar 5, 2016 at 1:54 PM West, Nathan <address@hidden> wrote:
On Sat, Mar 5, 2016 at 10:45 AM, Marcus Müller <address@hidden> wrote:
Hi Mike,

Following advice here I descended down a rabbit hole and tried to start again “pip uninstall pybombs”. Pip was not found.

Uninstalling pybombs via pip only makes sense if you've installed it via pip ("pip install pybombs"). Seemingly, you've either gotten PyBombs through different means, so investigating pip doesn't really make sense, or something uninstalled pip after you've installed it, and installed Pybombs with it. That would be strange.

I don't think that's true. It's unintuitive, but pip is the generally accepted way to uninstall anything installed through setup.py. See http://stackoverflow.com/questions/1550226/python-setup-py-uninstall
 

That has fixed the pip problem but not the UHD installation crash, but as a by product the error messages have become more verbose – and guess what? The problem is an undeclared type. THIS SAME ISSUE WITH UNDEFINED TYPES (shout so it sinks in, then repeat because it didn’t) THIS SAME ISSUE WITH UNDEFINED TYPES  that has been around for over a YEAR in UHD and in this case rx_dsp_core_200.cpp.

There is no such issue I know of. Now, that doesn't mean there's no issue, it just means that none of the other users I've talked to nor myself encountered it. However, probabilistically speaking, that's indicative of something being wrong with your system...

Every so often I point it out and someone fixes it and later on someone else (I wonder if this is the same person who broke it last time) then adds some new code somewhere else recreating the same errors. In this case its uintptr_t that is not declared.

Um, sorry, I don't even see uintptr_t in rx_dsp_core_200.cpp, and I've searched through its file history: It never occurred there. So to research this issue, I'll need your full "make" output. Maybe your version of Ubuntu fell off the testing bandwagon: which version of Ubuntu are you using?

A good motto is to assume nothing and please make sure you declare everything.

uintptr_t is a standard type. See "man stdint.h".


Looks potentially familiar... Two things might be going on. 1) If you have a UHD installed and the current build picks up on it things might get messy in non-intuitive ways. Make sure you remove any stray UHD installations. That seems likely in this case. 2) There's a similar issue with some versions of glibc and boost. See https://github.com/gnuradio/gr-recipes/pull/4#issuecomment-181188909 (seems unlikely in this case). BTW, if you see a problem in the code that keeps coming back you don't have to wonder who does it... you can use git to know. Anyway, indeed without errors/build logs I'm not sure what you expect anyone to do here.
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Very Respectfully,

Dan CaJacob

reply via email to

[Prev in Thread] Current Thread [Next in Thread]