From owner-freebsd-current@FreeBSD.ORG Mon Aug 26 01:21:22 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 75A21787 for ; Mon, 26 Aug 2013 01:21:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D49A2E43 for ; Mon, 26 Aug 2013 01:21:21 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so4093751ieb.31 for ; Sun, 25 Aug 2013 18:21:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=zFSCZTwm61Z1Vz3wlW9j/MomllmS/YWf0kmxM5KFMnw=; b=lPAJKZms98Sxyq3otjygrCniJ8E0JULGRAT2h1rJEQA435QdhKrGfsBJvaQeZ2GCu0 uOyDjb0Cmgd27FLdWJfjy9PvkEvYGoOzd6tGTlpWeVzJSozFgb/b1EDPN7arDnNsRWwF d4tVdd5NNTdf3oSflbb84SWge7W80+A5g8HzpspQvSXgdcmLjU0R/wPMp4oa5CeOKfps IKm36VtJ/pJnSneFj2u4N5MfVFv1xJAmpeYKq8ZfLkZic//vCkTALjmHo5BW1VvXWw0P yUBQ8QuseCnwlSOGhlKyi9+MrWZb90Czq1qH2KNbpWnvspkyS5NZ/aMuAT8bLqRr1IPu /2Rg== X-Gm-Message-State: ALoCoQmLKgmVLtibgnOQXZypgwxZiVXftFyFKbxikDjJB8Iju1HFBZp5k19HJGXFwYZKlK12WLtX X-Received: by 10.50.50.210 with SMTP id e18mr5107090igo.9.1377480081355; Sun, 25 Aug 2013 18:21:21 -0700 (PDT) Received: from 130.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id cl4sm15015055igc.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Aug 2013 18:21:20 -0700 (PDT) Sender: Warner Losh Subject: Re: patch to add AES intrinsics to gcc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 25 Aug 2013 19:21:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <066F5ACF-F2EA-42FF-8D27-BFE20E20B501@bsdimp.com> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <5217DBAB.5030607@freebsd.org> <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> <8C31A000-6806-4291-98A4-E8291E637BD2@bsdimp.com> To: Gerald Pfeifer X-Mailer: Apple Mail (2.1085) Cc: Adrian Chadd , re@freebsd.org, current@freebsd.org, John-Mark Gurney , Alfred Perlstein , toolchain@freebsd.org, "Sam Fourman Jr." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 01:21:22 -0000 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'=20= >>> toolchain support working correctly enough to build with this, why=20= >>> 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=20 >> FreeBSD. I'd say it is far too radical a departure and opens up a=20 >> huge can of "which version of what compiler" nightmare that we've=20 >> largely dodged to date because we had one (or maybe two) compilers=20 >> in the base system. >=20 > I am working towards establishing lang/gcc as _the_ version of GCC > to use for ports. >=20 > Today I looked at a couple of those GCC cross-compilers we have in=20 > 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. >=20 > 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