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
