This issue was found on system which had libstdc++ dynamic library not functional.
It is pointing to broken link which results in error:

/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.4.5/libstdc++.a(ios_init.o): relocation R_X86_64_32 against `pthread_cancel' can not be used when making a shared object; recompile with -fPIC

Each time dynamic library tries to use stdc++, as libstdc++.so was broken link.

Currently SlapOS requires "sane" host: which has working libc, libc++ and gcc.

Some day in future SlapOS node software can provide own compiler, toolchain
and libc with libc++.

This reverts commit 6819f5a8.

This solve compilation problems on Debian 6.0.1

It has more immunity on libnetworkcache errors.

Default value of 10 years should be enough.

This has to be done on software level.

* SECURITY: CVE-2011-3348 mod_proxy_ajp when combined with mod_proxy_balancer: Prevents unrecognized HTTP methods from marking ajp: balancer members in an error state, avoiding denial of service.
* SECURITY: CVE-2011-3192 core: Further fixes to the handling of byte-range requests to use less memory, to avoid denial of service. This patch includes fixes to the patch introduced in release 2.2.20 for protocol compliance, as well as the MaxRanges directive.

zope.conf is read quite lite during zope startup and some modules are using
environment variables to be set up (like DateTime) *before* zope.conf is read.

In the same time, it is useless to define to logformat when only
one is used. Using format closer to default apache allows to
more easily use various log parsers

For performance analysis, it is mandatory to keep logs for a very long
time. Also it is sometimes required to analyse a bug that happened
more than one more ago, so we have no other choices than keep logs
and not remove them.

slapos.recipe.build allows to install openoffice in same way as z3c.recipe.openoffice.
Additionaly it does not hardcode internally paths or binaries, so less code
updates are needed.