Date: Sat, 26 Jan 2013 04:28:56 -0800 (PST) From: Pedro Giffuni <pfg@freebsd.org> To: Mark Linimon <linimon@lonesome.com> Cc: freebsd-toolchain@freebsd.org Subject: Re: Removing default build of gcc Message-ID: <1359203336.70140.YahooMailMobile@web162105.mail.bf1.yahoo.com>
next in thread | raw e-mail | index | archive | help
Hello;=0A=0ASorry for top-posting: I am in a mobile device that doesnt know= better.=0A=0AI am aware that openoffice is also broken due to stlport.=0A= =0AThe situation is not too different from the fortran removal: for many re= asons it is convenient to use a pre-packaged compiler for many ports. Gcc 4= .2.1 is also becoming obsolete and is really difficult to maintain..=0A=0AP= edro. From owner-freebsd-toolchain@FreeBSD.ORG Sat Jan 26 15:22:37 2013 Return-Path: <owner-freebsd-toolchain@FreeBSD.ORG> Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 99153BF8; Sat, 26 Jan 2013 15:22:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id E9FA132E; Sat, 26 Jan 2013 15:22:36 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0QFMQ0k068582; Sat, 26 Jan 2013 17:22:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0QFMQ0k068582 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0QFMPBX068581; Sat, 26 Jan 2013 17:22:25 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Jan 2013 17:22:25 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: David Chisnall <theraven@FreeBSD.org> Subject: Re: Removing default build of gcc Message-ID: <20130126152225.GC2522@kib.kiev.ua> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <E0EA1F1F-99BB-47F5-94A3-1C197F680BD9@bsdimp.com> <20130125195941.GW2522@kib.kiev.ua> <F27709EE-6C8E-4943-BFAF-CF05AB34C1ED@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lEkl9o9W2JhK2ndV" Content-Disposition: inline In-Reply-To: <F27709EE-6C8E-4943-BFAF-CF05AB34C1ED@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain <freebsd-toolchain.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-toolchain>, <mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain>; List-Post: <mailto:freebsd-toolchain@freebsd.org> List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>, <mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sat, 26 Jan 2013 15:22:37 -0000 --lEkl9o9W2JhK2ndV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 26, 2013 at 10:23:58AM +0000, David Chisnall wrote: > On 25 Jan 2013, at 19:59, Konstantin Belousov wrote: >=20 > > 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 ? >=20 > 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. --lEkl9o9W2JhK2ndV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRA/SxAAoJEJDCuSvBvK1BnC0P/jFDdLKWB5ncHbwYEuKgsWAL LXdCOTtHkw4NI2mqpudFpg/qhHK2KWZ4RDpACQJnVuzKRdl7KeH5mLtpmMAG02YW l1KQbXQhGjhuNZBPF5MSSPo0b1T8iL79oM5pSdfI5EUa2J5CRrCr9fsTtqDL4TLK XE9kaL5VMjGCagi4I4yJCGA0fcDmUDWqS5vxILt5D8ej/cn4GTg9xC7Z2BOcCCnU 0ssAen+dsVhoBBKOo1BmEaUE6AhnwKZ2dZRuiTviWknz950pDFowu9eNqOv4vCY6 ZfXyjnU4N2qw0/8mDkzK9CZG3CkevGbuFArgLkF5jUnmOyB4bHSv2rg9he167DIp wHhyqWRJuA7gH7sYDE6oFMEvcScdUoQOag7p4/sjQ/xTUu2Iwyngh6R+heubI2M/ e1wQzldWLMJZCHAvzz0d9gvtdJ1Kh/FNqM7mg6WH5stP7P5hbBxmmKSwarDsTBbl 5NAADs795rq/StR2S+Ie2XendBfp0PGlEuM2DwLJuWGj3gnBkzhToHfB0ZzmO1A8 sCGtpe+h658XE1kuHa2xOz7TRxCYvcaqrOV6PGQe5EqOcCnyqkKKFiQK98Ui7q1l DNEwoFE7wuYaSI3v0R+EjA+gvIzabhBKQrGgJh0rE7uim+zzGIZVygngdI/HOBts K0LqjqnKFaHHfemZTwTv =eJqe -----END PGP SIGNATURE----- --lEkl9o9W2JhK2ndV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1359203336.70140.YahooMailMobile>