Re: Removing default build of gcc
On Sat, Jan 26, 2013 at 05:24:27PM +0200, Konstantin Belousov wrote: > Ports should use port-provided compiler, and be untangled from the base > toolchain. And when I get the use of the build cluster back, it's one of the bits of code I intend to work on. But we're not going to be able to do that in the near-term. mcl ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Removing default build of gcc
On 26 Jan 2013, at 15:22, Konstantin Belousov wrote: > 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. The test case in the PR was such a test case. libstdc++ and libsupc++ export a few symbols (including the ones that I mentioned in the email that you are replying to) with different versions. The end result is that you get some cases where some code (typically in libsupc++) I am not claiming that this is an rtld bug, so I don't know why you keep going on about it as if I am. I do not know why you want me to provide you with an isolated test case for a bug that is assigned to me and that I am in the process of fixing. > 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). This is COMPLETELY IRRELEVANT to the bug in question, which is that our libcxxrt and libsupc++ version scripts have some incorrect symbol versions. > 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. It is correct. I am not claiming it is incorrect. I don't know why you keep repeating that I am. > 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. I have a patch, which fixes it in some cases and has been tested, but misses some others. I am preparing a patch that fixes the versioning consistently across libsupc++ and libcxxrt to match libstdc++. I want to do this as a single patch, rather than an ad hoc series of changes. My aim is, as it has always been, to preserve the existing ABI. David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Removing default build of gcc
On Jan 26, 2013, at 5:28 AM, Pedro Giffuni wrote: > The situation is not too different from the fortran removal: for many reasons > 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.. Removing it before all the pieces are in place is even more disruptive. They aren't there, and we need to get people to fix the broken stuff first. Warner ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Removing default build of gcc
On Sat, Jan 26, 2013 at 02:53:16AM -0600, Mark Linimon wrote: > On Fri, Jan 25, 2013 at 03:36:15PM -0500, Pedro Giffuni wrote: > > I don't care much about gcc in current. > > clang, even on -9, can't build the following: > > - most of kde > - graphics/GraphicsMagick > - editors/emacs21 > - www/libxul19 > > any one of which I would consider showstoppers for making a gcc-less > system. IMO this is not the approach we should take in regard to gcc and ports. Ports should use port-provided compiler, and be untangled from the base toolchain. I believe that forcing ports committers to port 20K+ packages to clang is a waste of the FreeBSD resources and is is destined to fail despite the efforts. pgpTHTXzllHoH.pgp Description: PGP signature
Re: Removing default build of gcc
On Sat, Jan 26, 2013 at 10:23:58AM +, 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. pgpu2cXQjxZaw.pgp Description: PGP signature
Re: Removing default build of gcc
Hello; Sorry for top-posting: I am in a mobile device that doesnt know better. I am aware that openoffice is also broken due to stlport. The situation is not too different from the fortran removal: for many reasons 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.. Pedro. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Removing default build of gcc
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. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Removing default build of gcc
On Fri, Jan 25, 2013 at 03:36:15PM -0500, Pedro Giffuni wrote: > I don't care much about gcc in current. clang, even on -9, can't build the following: - most of kde - graphics/GraphicsMagick - editors/emacs21 - www/libxul19 any one of which I would consider showstoppers for making a gcc-less system. mcl ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
