[build2] Fix build on older x86 and arm CPUs

Norbert Lange nolange79 at gmail.com
Sat Dec 23 10:09:49 UTC 2017


2017-12-23 9:29 GMT+01:00 Boris Kolpackov <boris at codesynthesis.com>:
> Norbert Lange <nolange79 at gmail.com> writes:
>
>> I wouldn`t care (much) about performance in a build-system, compiler/linker
>> will dominate the build. Also, you only know that atleast ONE operations is
>> missing, often that's compare-and-swap.
>
> Yes, these are good points. Probably nobody sane will develop on those
> platforms so it will be from-scratch builds.

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).

>
>
>> https://github.com/nolange/deb-build2-toolchain/blob/master/debian/patches/add_atomic_lib.patch
>
> The patch has a bunch of portability issues (#warning is no portable,
> linking libatomic should only be done if using GCC's runtime).

The warning/error should be just removed IMHO. 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.

>
> I am wondering if instead the same (except for #warning) can be achieved
> by passing LIBS=-latomic and config.cc.loptions=-latomic from outside?
> The fact that GCC does not link libatomic automatically when necessary
> seems like a bug to me and apparently other people:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

Yeah, there was the same issue with libm. Problem is that you can use
gcc with other C/C++ libraries,
there are some good points of not making this logic too "smart". Can`t
really argument whats better.

>
> So if you can (and I think you should be able to) achieve linking to
> libatomic without modifying buildfiles, then I could do something to
> suppress the #error (probably add a macro to ignore lock-free issues).

The #error should be gone without replacement, I don`t see any value
added by it.
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.

is the aim for build2 to add featuretests like autotools/CMake?
Usually these switches would by tested by compiling small tests,
I know when bootstrapping this aint solving everything.

Norbert



More information about the users mailing list