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: Michael Dickens
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: Thu, 2 Jan 2020 11:42:36 -0500

Marcus got it: there are old headers around in some system prefix (possibly including "${CMAKE_INSTALL_PREFIX}/include"), which are being picked up by CMake and included ("-I...") -before- the internal-to-GR-build ones. The GR API changed, and because the old header is being used with the new code, the error is generated. I've investigated this issue & could figure out no good fix because of the way CMake handles the "include directories" internally between targets and the current build. Hence, my recommendation is to not build a new GR while an old one is installed in system prefix (etc). - MLD

On Thu, Jan 2, 2020 at 11:16 AM Marcus Müller <address@hidden> wrote:
Hi Tom,

funky distro!
That API used to be string (of a serialized PMT) and now is PMT
directly. That happened somewhere around July.
Thus, this slightly looks like you still have some older header files
lying around? Or some outdated SWIG output that somehow ends up in your
build?
Could you try in a clean container? I'm trying here locally, but
honestly, I've never used slackware before, and thus I need to learn
every packager tool in the process, and that's kind of a burden.

Best regards,
Marcus
On Thu, 2020-01-02 at 15:18 +0000, Tom Crane wrote:
> I am attempting to build the v.3.8 source under Slackware64 Linux
> and
> can't get past this and a few subsequent errors.
>
> Building from the git source results in the same failure.
>
> Build system details:
>   o gcc 9.2.0
>   o SWIG version 4.0.1
>   o Boost 1.72.0
>
> My build scripts and build logs are here
> https://www.mklab.rhul.ac.uk/~tom/tvdx/gr/build_problems/
>
> Please advise.
>
> Many thanks
> Tom Crane
>




--
Michael Dickens
Ettus Research Technical Support
Email: address@hidden
Web: https://ettus.com/

reply via email to

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