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 <n...@ostatemail.okstate.edu>
wrote:
> On Sat, Mar 5, 2016 at 10:45 AM, Marcus Müller <marcus.muel...@ettus.com>
> 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
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
--
Very Respectfully,
Dan CaJacob
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
