This makes configure smell more like standard configure scripts and
easier for larger build systems to control the nature of the build.
When building non-pic, don't build the shared object, as a non-pic
shared object doesn't make a huge amount of sense.
Besides implementing Thumb 2 supports, this fixes incorrect usage of
"cmp" where "cmpeq" was meant.
Patch submitted by Olivier Houchard <cognet@freebsd>.
build:
- configure step will generate relevant CFLAGS.
- build profiles are for convenience (developers can use themu
for cross-compilation).
regressions:
- Renamed ck_barrier unit tests to work-around behavior
of Solaris linker.
- Adopted use of a PTHREAD_CFLAGS variable.
ck_cc:
- Added internal CK_CC_IMM macro for compilers that are
verbose against impossible inline constraints (or limited
optimizers).
ck_pr/x86*:
- Adopted CK_CC_IMM macro.
- Dropped redundant constraints.
This work was mostly completed by Theo Schlossnagle
<jesus@omniti.com>, much thanks to him. He has
also provided access to a machine with Sun Studio 12.
Make the assumption that all of our 32-bit x86 architecture targets
have SSE and SSE2. This allows us to use MOVQ, which is nicer than
using cmpxchg8b for loads / stores.
Fix up some of the CAS stuff for -fPIC. This isn't entirely done,
and at least ck_fifo_mpmc hangs with this code. Not entirely sure
why.
Previously, we wouldn't build on 32-bit architectures, let alone
configure. This was due in part to some issues where we essentially
ignored setting CFLAGS properly.
In addition, FreeBSD and possibly other BSDs only report i386 for any
32-bit x86 architecture. This has the side-effect that we have to do
some additional guesswork to determine the actual CPU. Since we make use
of cmpxchg8b, we require an i586 machine. FreeBSD's default 32-bit gcc
-march setting is i486, so in effort to make things easier for FreeBSD
users on 32-bit, set that to i586 by default.
Linux makes this a little easier for us, since its uname actually
returns useful information about the architecture (and assumedly the
compilers for that architecture target the same arch at a minimum), so
we will refuse to work on i386 / i486 on Linux as well.
But really, I'd be slightly surprised at a ton of use on pentium/k5.
Wez Furlong
Samy Al Bahra
Samy Al Bahra
Samy Al Bahra
sbahra
Devon H. O'Dell