Removing default build of gcc

[Konstantin Belousov]

On Sat, Jan 26, 2013 at 10:23:58AM +0000, David Chisnall wrote:
> On 25 Jan 2013, at 19:59, Konstantin Belousov wrote:
> 
> > I am really tired of the constant struggle against the consumation of
> > the FreeBSD as the test-bed for the pre-alpha quality software. E.g.,
> > are we fine with broken C++ runtime in 9 ?
> 
> Please can you stop the FUD here? It really isn't helpful. We have a
> working C++ runtime in 9.1: libcxxrt. In fact, we have a working C++11
> stack in 9.1, with the combination of libcxxrt, libc++, and clang++.
> Unfortunately, the filter library configuration for libsupc++ left
> some symbols in the wrong symbol version (the ABI library version
> instead of the STL library version) and so there are some issues in
> corner cases[1], which I am working on fixing. I have a fix for the
> most common corner cases, but I want to make sure that I have caught
> all of them before I commit. This will happen tomorrow.
>
> The filter library is very important to have working for 10.0, because
> we will need the ports and compat versions of libstdc++ to use it if
> we want to be able to mix code that uses libstdc++ (i.e. any ports
> that don't work correctly with libc++) and libc++ (i.e. any ports that
> use C++11, which is going to be an increasing number over the next few
> years).
>
> David
>
> [1] In particular, terminate handlers are not correctly set, and
> exceptions thrown from the runtime library are not of the expected
> type. This means that C++ code that calls std::set_terminate() will
> not work and neither will code that calls __cxa_bad_alloc() and
> friends and then tries to catch the resulting exception. The only code
> I have seen that actually does this is a test case that I wrote for
> libcxxrt. In general, code encountering either of these problems is
> already in a very broken state and the only difference you will see is
> a less helpful error message before it crashes.

I do not see how the code demonstrated as failing in standards/175453
could be classified as 'broken' or 'so special that nobody does it'.
It is perfectly valid, and my reaction for such breakage is that C++
runtime is completely broken. How pointing to this fact can be FUD ?

Your initial assesment of the problem as a misbehaviour of the combination
of filtering and versioning made no sense to me, I asked you to provide
the isolated test case, which you did not.

Our implementation of filters indeed only allows for the filtered
symbol to have the same version as the filtee symbol. I re-read the
SUN documentation about filters (who had designed them), and looked at
what Linux does there. It seems to me that Sun document spirit forces
us to behave in a way which our rtld currently does. Linux behaviour is
useless there, IMHO, since their rtld just inserts filtee before filter
in the global lookup order (I may be wrong there).

I do suggest (again) that the way to fix the issue is to provide the
isolated test-case and decide if the behaviour of rtld is right. If we
conclude that the problem is not in rtld but in the versioning mismatch
between libraries (libstdc++ and libsupc++), I again suggest to provide
the patch for review first. The ABI seems to become too unwieldly, and
making ad-hoc changes there could paint us into the corner.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20130126/a59bb7ac/attachment.sig>