OpenLDAP: core dump with latest CLANG buildworld.

Hartmann, O. ohartman at
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.

Hello Dimitry.

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_...
>> statements?
> 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
> reserved.
> 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 mailing list