Date: Fri, 21 Jun 2013 23:21:32 +0200 From: Michael Gmelin <freebsd@grem.de> To: Dimitry Andric <dim@FreeBSD.org> Cc: "freebsd-ports@freebsd.org Ports" <freebsd-ports@freebsd.org>, Matthias Andree <mandree@FreeBSD.org> Subject: Re: Are ports supposed to build and run on 10-CURRENT? Message-ID: <20130621232132.34bb67b5@bsd64.grem.de> In-Reply-To: <EF830CD7-00F1-4628-8515-76133BBE85E7@FreeBSD.org> References: <20130613031535.4087d7f9@bsd64.grem.de> <EF830CD7-00F1-4628-8515-76133BBE85E7@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21 Jun 2013 22:07:56 +0200 Dimitry Andric <dim@FreeBSD.org> wrote: > On Jun 13, 2013, at 03:15, Michael Gmelin <freebsd@grem.de> wrote: > > I've been waiting for > > http://www.freebsd.org/cgi/query-pr.cgi?pr=179233 to get committed > > for a little while now. > > > > 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. > > > > I *did* test the port thoroughly and successfully on current RELEASE > > versions in various combinations though: > > > > - system gcc + system libstdc++ > > - system clang + system libstdc++ > > - system clang + std=c++11 + system libc++ > > > > 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: Also all other tests that actually include generated code from slices fail as well (I tried about ten of them, after that I gave up and figured it is a general problem). Ice had a problem like that before, when it relied on some implementation detail of gcc, so testing is always important and that's why I changed the port to make unit tests run by default. > > [...] > *** 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. Sounds plausible. > > 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. Absolutely. > > > > - system clang + std=c++11 + system libc++: Build fails, due to > > 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. Interesting, since it builds fine on 9.1 using clang 3.1 - so probably that version of clang didn't implement atomic_init yet (too lazy to check right now). > > 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. Hard to tell, but you're probably right. This kind of proves my point though, that trying to make things work for CURRENT is a lot of work and pain, especially when using complex ports that might have issues created upstream. I already fixed many issues to make it works fine on RELEASE, but there are resource constraints and I simply can't fix these kinds of things before there's a release candidate. Thanks for your in-depth analysis though, much appreciated. I will look at this once I have a little bit more time and 9.2 gets closer - afaik it will include a more recent version of clang which might very well cause the same issues - testing on 9.1 with clang from ports might prove that. I will also contact upstream about this - since they support OS X as a primary platform and XCode is using clang I'm pretty certain that they'll face the same issue sooner or later anyway. This raises another question though - how should ports handle "-std" and "-stdlib" in the future? We run a complete toolchain based on clang, c++11 and libc++ here on 9.1 quite successfully, but it requires a lot of work to get everything going. Since more and more projects will start using c++11 (and therefore libc++ as well) to make use of the new features and since mixing C++ libraries built with different versions of the standard and different standard libraries in general doesn't work - or if it does produces sometimes quite unexpected results - having some ports support for this beyond setting CXXFLAGS, testing, patching and hoping for the best would be great. Cheers, Michael > > -Dimitry > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to > "freebsd-ports-unsubscribe@freebsd.org" -- Michael Gmelin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130621232132.34bb67b5>