Re: [gpsd-dev] gpsd fails to build on mac 10.7

[Andy Walls]

Use the nop() barrier from libatomic_ops?
http://www.hpl.hp.com/research/linux/atomic_ops/

Or maybe use the memory barrier in OpenPA (Open Portable Atomics)?

These are results from Google; I have no experience with either library. 

I would assume one does not want  to reinvent a cross platform atomic ops/memory barrier library of functions that already exists.

Regards,
Andy

Greg Troxel <address@hidden> wrote:

I think there are several problems.  One is the new insistence on memory
barriers, but the barriers are a gcc extension, not anything in
standards.

My system has three compilers:

gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn)

while these might be not the newest, they are hardly ancient and crufty.

So it seems the immediate fix is that barrier() should just be defined
as a no-op if there isn't compiler-specific fix.

Has anyone actually seen a bug due to missing barriers?  (I get the
theory.)

What is one supposed to do while complying with C99 and POSIX?  Relying
on gcc extensions is very 00s.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.