Hi Jameson,
don't overdo it! Johannes' approach might really be the more sensible here!
On 03.10.21 22:06, Jameson Collins wrote:
> So I haven't forgotten about this, it's just turned into more work than
> expected. The
> target didn't have perf, and it turns out there was a kernel bug that mad
> GNU Radio has released v3.8.4.0 and v3.9.3.0, hitting the September target
> date with hours to spare. For details, see the Github release pages:
>
> https://github.com/gnuradio/gnuradio/releases/tag/v3.8.4.0
> https://github.com/gnuradio/gnuradio/releases/tag/v3.9.3.0
>
> Next releases are exp
That's not a boost problem, it's a gcc problem. You have to use at least
gcc 8 for v3.9.3.0.
Ron
On 10/4/21 4:54 AM, Wojciech Kazubski via GNU Radio, the Free &
Open-Source Toolkit for Software Radio wrote:
GNU Radio has released v3.8.4.0 and v3.9.3.0, hitting the September target
date with h
> That's not a boost problem, it's a gcc problem. You have to use at least
> gcc 8 for v3.9.3.0.
>
> Ron
>
Thanks for quick help.
The compiler is GCC 7.5 and there is a warning, it worked somehow with GR
3.9.2. but now isn't.
--
Wojciech Kazubski
We only require C++14 but the compilers we test with support some C++17
features, e.g., filesystem. You are right that this change was made between
3.9.2.0 and 3.9.3.0. We should have put in an ifdef for backward
compatibility here. If you change that line to boost/filesystem, does it
work? That ap
Added issue https://github.com/gnuradio/gnuradio/issues/5134.
On Mon, Oct 4, 2021 at 9:22 AM Jeff Long wrote:
> We only require C++14 but the compilers we test with support some C++17
> features, e.g., filesystem. You are right that this change was made between
> 3.9.2.0 and 3.9.3.0. We should h
Issue fixed on maint-3.9, for those who do not have recent compilers.
On Mon, Oct 4, 2021 at 9:28 AM Jeff Long wrote:
> Added issue https://github.com/gnuradio/gnuradio/issues/5134.
>
> On Mon, Oct 4, 2021 at 9:22 AM Jeff Long wrote:
>
>> We only require C++14 but the compilers we test with sup
Adding (hopefully not just noise) to this thread, I am curious as to
whether my stopping flow graphs that contain a QT GUI time sink or
frequency sink resulting in a segmentation fault is related to gr built
with 8.2.1 while opensuse Leap 15.2 system libraries were built with GNU
C++14 (SUSE Linux)
Note on compilers: a "may not work" warning is printed during cmake if the
gcc version is < 8.3.0. So, 7.5.0 is not really supported, even though it
may have worked in the past.
On Mon, Oct 4, 2021 at 5:16 PM Aardric wrote:
> Adding (hopefully not just noise) to this thread, I am curious as to
>
The segfault also happens on Ubuntu 18.04 and gcc >= 8. It is exposed by
these commits.
https://github.com/gnuradio/gnuradio/commit/1e661918ad4fd096b2c990354c316602813246c7
https://github.com/gnuradio/gnuradio/commit/9f8ed5bb5decdcc6905e4a8cbd22ac31bca619a7
It appears to be related to the Qt v
10 matches
Mail list logo
