Re: [gpsd-dev] Fedora 24, gcc 6.1.1 - 'memory_order_seq_cst' was not declared in this scope

[Fred Wright]

On Sun, 23 Oct 2016, Bernd Zeimetz wrote:
> On 10/15/2016 01:24 AM, Fred Wright wrote:
> >> The reason for that is that scons compiles c++ code with cflags only
> >> somewhere - I think in the qt library stuff. Not sure where exacly, but
> >> it will barf if you remove it from cflags. Better patches are welcome :)
> >
> > Does putting it in CCFLAGS work?
>
> If I remember right - no. But thats long ago that I messed with it.

OK.  I'd planned to take a look at that "atomic" stuff at some point,
anyway, since the current implementation relies on a fairly recent and
widely unavailable language feature, while GCC has had intrinsics that can
accomplish the same thing since around 4.0 or 4.1.  But they're not just a
drop-in replacement, so it would require some work in both the code and
the build procedure.

> > Bernd:
> >
> > Since you're here, how about responding to:
> >
> > http://lists.nongnu.org/archive/html/gpsd-dev/2016-09/msg00067.html
> >
> > This relates to your patch.
>
> sorry, seems my spam filter ate that mail.

That may have been a conspiracy between the mailserver and myself.  I CCed
you on the message to make it "more likely" that you got it, but the
mailserver dedups messages CCed to recipients, so you probably got *only*
the non-mailserver copy, which may have been blocked.

I also emailed you once privately months ago regarding GPSD packaging,
with no response, so that may have been similarly blocked.  You might
consider whitelisting my email address, or emailing me privately with some
other filter-bypass trick.

> If you can't reproduce it, you are probably using a different compiler.

When testing on OSX, I even tried forcing a non-default GCC 6
(exacerbating another bug in the process) without seeing it.

It's also not clear to me how a warning turns into an error without
explicitly requesting that behavior.

> I have no idea how to remove -w options for check functins in scons.

Currently all the non-default warnings are tested and added at the
beginning of the Configure section.  I think it would be a good idea in
general (not just for this) to move that to the end of the Configure
section, so that all the "real" checks are performed with only the default
warnings.  I suspect (without the ability to verify it) that this would
fix the issue.

> Also I think esr might want to take that issue to the scons developers,
> so having a real fix for the issue makes more sense.
> imho scons is broken by design and not fixable, I only mess with it if I
> need to make gpsd build yet again.

I agree that the current CheckFunc is somewhat broken (and for some reason
more so than other Configure checks) and worth fixing in SCons itself, but
I don't think it needs to be fixed (or replaced) for the GPSD build to
work.  So far, it appears that you're the only person in a position to
verify an alternate fix.

My time to work on GPSD is likely to be limited for the next couple of
weeks, but I can probably make and test the aforementioned change to the
Configure section, leaving the testing of undoing the CheckFunc fix to
someone who can actually reproduce the problem.  Although actually
reverting the CheckFunc patch requires resolving a conflict, for test
purposes it's sufficient to change the one call on
CheckFuncFor_Wstrict_prototypes() back to CheckFunc().

Meanwhile, I guess I should dump my current "patch buffer" to the list.
:-)

Fred Wright