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 influence. > > > ... >> 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?Received on Fri May 04 2012 - 19:27:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:26 UTC