Build error GNU Radio release v3.3.1git-971-ga02bb131

Hi List,

I was trying to build the gnuradio on yet another machine running
Ubuntu 10.10. from source today after checking out the latest code
from the dev trunk:

git clone

Then I set the branch to next, so that I can build gr-uhd as well.
(Prior to this I’d successfully built and installed UHD)

After ./bootstrap, ./configure (reports most of the components (that I
want) will be built, including uhd), I run make and get the following
error, when make enters the /host/swig directory

make[6]: Entering directory `/home/siva/calit2/gnuradio/usrp/host/swig’

The reported bunch of errors are:

starts from:
python/ error: ptrdiff_t does not name a type

make[6]: *** [_usrp_prims_la-usrp_prims.lo] Error 1
ends after make exits the build tree…



Hello Arya,

AS> I was trying to build the gnuradio on yet
AS> another machine running Ubuntu 10.10. from
AS> source today after checking out the latest
AS> code from the dev trunk:

I see Ubuntu 10.10 has native packages. Is there a
reason why you need to compile it? Perhaps you are
looking for the latest and greatest.

You may have dependency problems. These
dependencies may be resolved by installing the
native packages. Perhaps you can open Synaptic and
install the native gnuradio that way and see if
that helps your compile process.

Best regards.

… …-. / -.-- — …- / .-. . .- -… / - … … …
.-… . - … / … .- …- . / .- / -… . . .-.

Jared Harvey Operator KB1GTT

e-mail [email protected]
Web page

Hi Jared, thanks for that suggestion.

Anyway, I realized that I was using GNU compiler gcc-4.6
(experimental) which apparently imposes stricter rules and allows
package builds to fail where previous versions used to succeed. So the
suggested fix for one typical “ptrdiff_t does not name a type” is
#include <cstddef.h>, which I did in the
/usrp/host/swig/python/ file, and the build completed to


On Sun, Feb 27, 2011 at 6:51 AM, Arya S.
[email protected]wrote:


Thanks for bringing this up (and for the solution). The
is actually generated by SWIG, so I’ve explicitly included stddef.h into
.i file, which is done for most of the other SWIG files already for
reasons. This really seems like a SWIG problem, so hopefully this will
fixed in future releases before the new GCC takes over. Hopefully, this
fixes our last hole, anyways.

I’ll be pushing changes to next and master soon.


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs