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

[Dimitry Andric]

On Jun 13, 2013, at 03:15, Michael Gmelin <freebsd at 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:

[...]
*** 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=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.

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