Previously, we would simply fail if the architecture was not
a first-class citizen. However, we have always allowed a built-in
fallback in code.
Instead, allow for people to direcly use the builtin fallback without
having to provide their own profiles and emit a loud warning.
expr as provided by busybox doesn't know about --, while most other
implementations require it, or it'd try to interpret --prefix=whatever as
one of its own options. To fix this, we just remove the first two characters
of the option before calling expr, rendering -- useles.
Add a new configure option, --enable-lse, which is only effective for
the AArch64 architecture. When used, most ck_pr_* atomics will use Large
System Extensions instructions as per the ARMv8.1 specification, rather
then LL/SC instruction pairs.
--platform let you set the platform, instead of relying on uname -m
--use-cc-builtins force the usage of gcc atomic builtins, instead of using the one provided by CK.
otherwise configure doesnt finish properly.
example:
CC=gcc ./configure --profile=arm
make
...
gzip: /doc/CK_ARRAY_FOREACH: No such file or directory
gzip: /doc/ck_array_buffer: No such file or directory
Makefile:161: recipe for target 'all' failed
make[1]: *** [all] Interrupt
Makefile:23: recipe for target 'doc' failed
This was accidentally grouped into previous commit.
The destiny of this interface for internal use is still unclear (in context of
utilization in built-in data structures). The interface is enabled by default
on x86, as it is compatible with read-side prefetch* operations and
binary-compatible with 3DNow! extension. Older compilers will waste an
additional byte (they generate 3DNow! variant) on this, but older compilers
waste more on spillage if we encode instruction. Power support is coming soon.
_BSD_SOURCE is now deprecated in favor of _DEFAULT_SOURCE.
Use _DEFAULT_SOURCE, but retain _BSD_SOURCE for backwards
compatibility.
Thanks to Phil Sorber (PSUdaemon) for patch and investigation.
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.
When building and installing to a non-standard directory on OSX (for
example: when testing multiple versions of CK) it is desirable for
clients of CK to have the install_name match the installed location,
otherwise they need to resort to setting DYLD_LIBRARY_PATH to pick up
the library.