Linux ARM depends on running a Linux kernel 2.6.15 or better, GCC 4.4 or
better.
+The C compiler used needs to support at least C99. The C++ compiler used
+needs to support at least C++11.
+
The GCC compiler versions 3.3, 3.4, 4.0, 4.1, 4.2, 4.3, 4.4 and 4.5 are
supported, with the following exceptions:
Clang version 3.0 (based on LLVM 3.0) is supported.
+Glibc >= 2.4 should work but the older version we test against is
+currently 2.17.
+
For developers using the Git tree:
This source tree is based on the autotools suite from GNU to simplify
------------
In addition to the usual `make check` target, Userspace RCU features
-`make regtest` and `make bench` targets:
+`make regtest`, `make short_bench` and `make long_bench` targets:
- `make check`: short tests, meant to be run when rebuilding or
porting Userspace RCU.
- `make regtest`: long (many hours) test, meant to be run when
modifying Userspace RCU or porting it to a new architecture or
operating system.
- - `make bench`: long (many hours) benchmarks.
+ - `make short_bench`: short benchmarks, 3 seconds per test.
+ - `make long_bench`: long (many hours) benchmarks, 30 seconds per test.
+
+
+Known issues
+------------
+
+There is an application vs library compatibility issue between
+applications built using Userspace RCU 0.10 headers linked against
+Userspace RCU 0.11 or 0.12 shared objects. The problem occurs as
+follows:
+
+ - An application executable is built with _LGPL_SOURCE defined, includes
+ any of the Userspace RCU 0.10 urcu flavor headers, and is built
+ without the -fpic compiler option.
+
+ - The Userspace RCU 0.10 library shared objects are updated to 0.11
+ or 0.12 without rebuilding the application.
+
+ - The application will hang, typically when RCU grace period
+ (synchronize_rcu) is invoked.
+
+Some possible work-arounds for this are:
+
+ - Rebuild the application against Userspace RCU 0.11+.
+
+ - Rebuild the application with -fpic.
+
+ - Upgrade Userspace RCU to 0.13+ without installing 0.11 nor 0.12.
Contacts