From owner-freebsd-ports@FreeBSD.ORG Fri Jun 21 20:07:59 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 590CFB20; Fri, 21 Jun 2013 20:07:59 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id D78551265; Fri, 21 Jun 2013 20:07:58 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::a492:89ed:68f3:5154] (unknown [IPv6:2001:7b8:3a7:0:a492:89ed:68f3:5154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 7E46E5C44; Fri, 21 Jun 2013 22:07:56 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Are ports supposed to build and run on 10-CURRENT? From: Dimitry Andric In-Reply-To: <20130613031535.4087d7f9@bsd64.grem.de> Date: Fri, 21 Jun 2013 22:07:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130613031535.4087d7f9@bsd64.grem.de> To: Michael Gmelin X-Mailer: Apple Mail (2.1508) Cc: Matthias Andree , "freebsd-ports@freebsd.org Ports" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 20:07:59 -0000 On Jun 13, 2013, at 03:15, Michael Gmelin wrote: > I've been waiting for = http://www.freebsd.org/cgi/query-pr.cgi?pr=3D179233 > to get committed for a little while now. >=20 > The person looking at it today decided to test it on 10-CURRENT, which > failed (it built, but unit tests fail with all kinds of bus errors > on exit). It's not entirely clear what the issue is, but since Ice is = a > very complex port there are many possible reasons why it might fail. >=20 > I *did* test the port thoroughly and successfully on current RELEASE > versions in various combinations though: >=20 > - system gcc + system libstdc++ > - system clang + system libstdc++ > - system clang + std=3Dc++11 + system libc++ >=20 > I reproduced the problem on 10-CURRENT, the test results are: > - system gcc + system libstdc++ : Build ok, Unit tests *ok* > - system clang + system libstdc++: Build ok, Unit tests fail I have tried this combination on head as of r252060, and while most of the tests go well, the Slice/keyword test fails: [...] *** running tests 9/83 in = /usr/work/usr/ports/devel/ice/work/Ice-3.5.0/cpp/test/Slice/keyword *** configuration: Default *** test started: 06/21/13 21:30:02 starting client... ok Testing operation name... ok unexpected exit status: expected: 0, got -10 I took a look at the code for the test case, and it turns out that it relies on the order of construction and destruction of global objects, which is undefined in C++. So either the tests or the library itself is at fault. That it appears to work correctly with other releases and/or compilers is just coincidence. Specifically, the global const object '__F__and__return__Init __F__and__return__i' in Ice-3.5.0/cpp/test/Slice/keyword/Key.cpp, around line 81, which calls ::IceInternal::factoryTable->removeExceptionFactory("::and::return"), while the factoryTable global is already destroyed. This leads to a segfault. (The factoryTable global is destroyed prematurely, because it depends on the order of global static factoryTableInitializer objects.) I think the only way this is going to work in all cases, is by revising the factoryTable reference counting system, but this should probably be coordinated with upstream, and not with a local hack. > - system clang + std=3Dc++11 + system libc++: Build fails, due to=20 > a dependency (databases/db5) not building with those flags. It looks > like a problem in libc++ to me, but I didn't have much time to > investigate. It might be one of those things that might just go away > after a while. No, db5 does not build because it is redefining a C++11 standard library identifier, atomic_init(). It should probably prefix all its internal defines with 'db_', to avoid collisions. The db-5.3.21/src/dbinc/atomic.h file is already patched by our port to avoid one such collision, but it is probably necessary to do this again for any other identifiers that are used either by C++, or are compiler builtins. That said, I don't think building Ice with c++11 and libc++ will make all tests succeed, since the global initialization order issue is still there. This is the most important problem that should be fixed, at least eventually. -Dimitry