OpenLDAP: core dump with latest CLANG buildworld.
ohartman at zedat.fu-berlin.de
Fri May 4 21:27:13 UTC 2012
On 05/04/12 23:10, Dimitry Andric wrote:
> On 2012-05-04 10:40, Hartmann, O. wrote:> On all FreeBSD 10-CURRENt boxes, built with CLANG, there is no OpenLDAP
>> anymore since yesterday's buildworld!
>> OpenLDAP (slapd), the most recent build from the ports (recompiled
>> everything in hope to fix the problem) coredumps immediately after it
>> tries to start. Examination of the cause with slapd -d256 doesn't work.
> Which version of openldap did you use? I built openldap24-server with
> its default settings, and it starts up just fine.
On all boxes in question (FreeBSD 10.0-CURRENT/amd64) I have running the
most recent OpenLDAP (with SASL) 2.4.31 (portsnap on daily basis).
Database backend is databases/db5.
As I reported, compiled with legacy gcc 4.2.1 it starts up fine, too.
But it is worthless since whenever a connection (via TLS) is made to the
server (slapd), slapd crashes.
I worked yesterday with both boxes and the very same environment
(OpenLDAP/SASL 2.4.31, DB5) and rebuild world this morning which made
the server going rogue ...
Have you tried creating a LDAP DIT with some users? Have you compiled
OpenLDAP with gcc or clang? As said, with clang compiled, it crashes
when being started.
I also recompiled net/openldap-sasl-server and -client via "portmaster
-f openldap". It doesn't change much.
My configuration uses TLS for secure server communication - I will
mention this just in case the OpenSSL commits of yesterday do have an
>> Recompiling everything prerequisit for OpenLDAP/SASL revealed that even
>> now databases/db5 isn't compiling with CLANG anymore (which has before
>> the last LLVM update).
>> What happened? Why is CLANG (3.1?) now so picky about some __atomic_...
> This is because bdb5 tries to redefine gcc's builtin atomic functions,
> which are also supported by clang (this is a feature :). It is rather
> dumb to use names starting with underscores for this, since they are
> The same problem occurs if you compile with gcc 4.7 or higher, albeit
> gcc apparently doesn't think this is serious enough to bail out:
> ./libtool --mode=compile /usr/local/bin/gcc47 -c -I. -I./../src -D_THREAD_SAFE -O2 -pipe -fno-strict-aliasing ../src/mutex/mut_tas.c
> libtool: compile: /usr/local/bin/gcc47 -c -I. -I./../src -D_THREAD_SAFE -O2 -pipe -fno-strict-aliasing ../src/mutex/mut_tas.c -fPIC -DPIC -o .libs/mut_tas.o
> In file included from ./../src/dbinc/mutex_int.h:12:0,
> from ./../src/dbinc/mutex.h:15,
> from ./db_int.h:1089,
> from ../src/mutex/mut_tas.c:11:
> ./../src/dbinc/atomic.h:179:19: warning: conflicting types for built-in function '__atomic_compare_exchange' [enabled by default]
> In any case, attached is a simple patch to fix the db5 port.
Well, LLVM/CLANG 3.0 wasn't so picky about this redefinition, 3.1 is
obviously. I never tried gcc 4.7, I should do next time.
I will apply the patch. Thanks for it. Does the patch go into databases/db5?
More information about the freebsd-current