Re: gnuradio-3.8 build fails with error: cannot convert const string {aka const std::__cxx11::basic_string<char>} to pmt::pmt_t {aka boost::shared_ptr<pmt::pmt_base>}

[Martin Braun]

It might also be a cmake bug on our end. In my case, I deleted the system version and that fixed it. 

M

On Mon, 6 Jan 2020, 04:34 Marcus Müller, <address@hidden> wrote:

Update: we've been able to reproduce that SWIG uses whatever headers
are installed in the system[1]; so that really looks like a SWIG bug.
Martin had quite the time of his life, looking at *why* SWIG thinks
that would be appropriate.

Best regards,
Marcus

[1] https://github.com/gnuradio/gnuradio/pull/3020
On Fri, 2020-01-03 at 20:36 +0100, Marcus Müller wrote:
> Hi Tom,
>
> no, that's not expected and also doesn't reflect my experience with
> building GNU Radio. In fact, it's surprising: when you read `man gcc`
> on the `-I` flag, it's pretty certain that the explicitly specified
> include directories are scanned before the system ones are.
>
> Also, when reading your build log: the old thing is in the compiled
> SWIG-generated .cxx, and it uses the right, in-tree header. So, this
> is
> twice suspicious.
>
> Best regards,
> Marcus
>
> On Fri, 2020-01-03 at 17:31 +0000, Tom Crane wrote:
> > Hi Marcus,
> >     The problem was a lot easier to fix than I had expected.  It
> > was
> > simply that I had gnuradio-3.7.13.2 installed!  After removing it
> > gnuradio-3.8.0.0 built w/o problem.  Is this the expected behaviour
> > -- ie.
> > that one shouldn't try to build a new version gnuradio on a machine
> > that
> > has a copy of a previous version installed?
> >
> > To put it another way: Shouldn't a new build use its own header
> > files
> > in
> > preference to any installed in /usr/include etc.?
> >
> > Thanks
> > Tom.
> >
>
>