Re: patch to add AES intrinsics to gcc

On Aug 25, 2013, at 7:12 PM, Gerald Pfeifer wrote:

> On Sat, 24 Aug 2013, Warner Losh wrote:
>>> "If you push gcc out to a port, and you have the 'external compiler' 
>>> toolchain support working correctly enough to build with this, why 
>>> don't we just push clang out to a port, and be done with it?"
>> This is a stupid idea. It kills the tightly integrated nature of 
>> FreeBSD. I'd say it is far too radical a departure and opens up a 
>> huge can of "which version of what compiler" nightmare that we've 
>> largely dodged to date because we had one (or maybe two) compilers 
>> in the base system.
> 
> I am working towards establishing lang/gcc as _the_ version of GCC
> to use for ports.
> 
> Today I looked at a couple of those GCC cross-compilers we have in 
> ports, and I have to admit I am not thrilled.  Each of those I saw
> copies a lot from (older version of my ports), each has a different
> maintainer, each has some additions, and there is little consistency.
> 
> Are these the base of 'external compiler' toolchain support?  Are
> there any plans to increase consistency and reduce redundancy?  In
> an ideal world, could those become slave ports of lang/gcc?

In my experience, this has grown up rather hap-hazardly. Some more order here would be good. In the past, for example, some ports had some of the FreeBSD fixes, but not all so while I could build FreeBSD/mips gcc out of /usr/src, I couldn't do that, even for the (then current) gcc42 port since some of the fixes hadn't made it up stream.

In an ideal world, we'd be able to build any version of gcc for any FreeBSD platform (or have it fail up front) so we can use that as an external toolchain.

The initial work I did for external toolchains, that Brooks reworked (or rewrote from scratch, I can't recall which he did), was with make xdev in the tree...  And that has its own set of pros and cons...  All of which are really a tangent, so I'll leave it at that.

Warner