[build2] Fix build on older x86 and arm CPUs

Boris Kolpackov boris at codesynthesis.com
Sat Dec 23 12:25:13 UTC 2017


Norbert Lange <nolange79 at gmail.com> writes:
 
> Well, not on CPUs missing those ops, but thats only half the truth.
> distros like debian support those old CPUs, means you have to be able to
> generate code that works on those, even if everyone running dev-software
> will have CPUs that fully support atomics (and gcc/llbatomic will
> dynamically decide to use the instructions).

I don't believe that decision is dynamic, i.e., at runtime. My understanding
is that it's decided at compile-time based on the target CPU.

 
> The warning/error should be just removed IMHO.

The error is used to make sure we don't use anything non-lock-free on
modern platforms. So a macro that basically says, "yes, I understand
things won't be lock-free" is the way to go.


> Perf issues are something you deal with when you have concrete issues,
> and if there is no support in the toolchain you WILL notice, but possibly
> later when linking.

Again, you are only thinking about GCC/libstdc++. For example, on Clang
with libc++ things may just silently becomes non-lock-free (I actually
don't know what Clang/libc++ do in this case). Same goes for MSVC.


> I can live with passing in args/env-vars but I am not sure why this is
> different to linking -lpthread which is just coded in.

The difference with -lpthread is that (1) it is always needed (at least
conceptually) and (2) it is available on all the modern platform/compiler/
runtime combinations we care to target.


> is the aim for build2 to add featuretests like autotools/CMake?

While we may still end up supporting something like this, at this stage
we are trying hard to avoid it and instead base decisions like this
on "static" information about compiler/target. So far it has been
going[1] reasonably well.

[1] https://stage.build2.org (see, for example, libmysqlclient for some
    non-trivial buildfile).

Boris



More information about the users mailing list