On Jul 2, 2012, at 7:37 AM, Kristian Fiskerstrand wrote:
> This is rarely necessary and should be done only when the
> default configuration selects the wrong mutex implementation.
Is Gentoo3 or Gentoo4 selecting the wrong mutex implementation?
The deep underlying reason for using pthread_mutex is
Do multi-thread and multi-process locks use the same mechanism?
The pthread_mutex implementation using futexes is likely intrinsically faster,
and pthread_mutexes unify interprocess and inter-thread locks in the same
mechanism.
Statically library linking in a multlib environment has some tricky build
prerequsites to find pthread_mutex() in an arch-specific static library
on a multlib peculiar path. Add the build prereqa, not change the mutex
implementation, is the better solution imho.
The --enable=o_direct should likely not be used on linux too:
http://kerneltrap.org/node/7563
I've personally tried O_DIRECT with no improvement tuning bdb in rpm.
But they are all build options to use however one wishes: but the criteria
to decide what options to use are rather murky.
Here is what I have used for years (including RHL/RHEL3/RHEL4 Berkeley DB)
can be found in many dbXY.spec files is mostly similar to what you used:
%configure -C --srcdir=../dist/ \
--includedir='${prefix}/include/%{name}' \
--program-transform-name=s,^db,%{name}, \
--enable-compat185 --enable-dump185 \
--enable-shared --enable-static \
--enable-cxx \
--enable-sql \
--enable-sql_codegen \
--enable-stl \
%ifarch %{java_arches}
--enable-java \
%else
--disable-java \
%endif
# --enable-jdbc \
# --with-cryptography=yes \
# --with-stacksize=SIZE \
# --with-uniquename=SUFFIX \
# --with-pic \
# --with-gnu-ld \
# --enable-jdbc --with-jdbc=DIR \
# --enable-perfmon-statistics \
# --enable-dtrace \
# --enable-systemtap \
# --enable-umrw \
# --enable-test \
# --enable-debug --enable-debug_rop --enable-debug_wop \
# --enable-diagnostic \
DIsclaimer:
They are all build options to use however one wishes: but the criteria
to decide what options to use is rather murky. YMMV, everyone's does.
hth
73 de Jeff
_______________________________________________
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
