discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: gnuradio-3.8 build fails with error: cannot convert const string {ak


From: Marcus Müller
Subject: 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>}
Date: Mon, 06 Jan 2020 13:33:50 +0100
User-agent: Evolution 3.30.5 (3.30.5-1.fc29)

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.
> > 
> 
> 




reply via email to

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