From owner-freebsd-current@FreeBSD.ORG Fri May 4 21:27:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 606241065670 for ; Fri, 4 May 2012 21:27:13 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 177698FC14 for ; Fri, 4 May 2012 21:27:13 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1SQQ1w-0001sN-2K>; Fri, 04 May 2012 23:27:12 +0200 Received: from e178032166.adsl.alicedsl.de ([85.178.32.166] helo=munin.geoinf.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1SQQ1v-0006EM-Ua>; Fri, 04 May 2012 23:27:12 +0200 Message-ID: <4FA449AE.3050300@zedat.fu-berlin.de> Date: Fri, 04 May 2012 23:27:10 +0200 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120504 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4FA395E8.9050606@zedat.fu-berlin.de> <4FA445C4.7060709@andric.com> In-Reply-To: <4FA445C4.7060709@andric.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.32.166 Subject: Re: OpenLDAP: core dump with latest CLANG buildworld. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 21:27:13 -0000 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?