Are ports supposed to build and run on 10-CURRENT?

Michael Gmelin freebsd at
Fri Jun 21 21:21:42 UTC 2013

On Fri, 21 Jun 2013 22:07:56 +0200
Dimitry Andric <dim at> wrote:

> On Jun 13, 2013, at 03:15, Michael Gmelin <freebsd at> wrote:
> > I've been waiting for
> > 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.


> > - 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.


> -Dimitry
> _______________________________________________
> freebsd-ports at mailing list
> To unsubscribe, send any mail to
> "freebsd-ports-unsubscribe at"

Michael Gmelin

More information about the freebsd-ports mailing list