From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1FyUjB-0007Uo-FZ for garchives@archives.gentoo.org; Thu, 06 Jul 2006 14:21:13 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k66EKDUa006252; Thu, 6 Jul 2006 14:20:13 GMT Received: from smtp-out3.blueyonder.co.uk (smtp-out3.blueyonder.co.uk [195.188.213.6]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k66EH0VC001198 for ; Thu, 6 Jul 2006 14:17:00 GMT Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1FyUf5-0000dq-QD for gentoo-dev@lists.gentoo.org; Thu, 06 Jul 2006 15:16:59 +0100 Received: from [82.41.57.20] (helo=snowdrop.home) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1FyUf5-0001Kh-7B for gentoo-dev@lists.gentoo.org; Thu, 06 Jul 2006 15:16:59 +0100 Date: Thu, 6 Jul 2006 15:16:55 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Replacing cpu-feature USE flags Message-ID: <20060706151655.1edaa10f@snowdrop.home> In-Reply-To: <44AD1843.1090707@gentoo.org> References: <200607061252.33028@enterprise.flameeyes.is-a-geek.org> <20060706131905.3ba12b49@snowdrop.home> <200607061429.39803@enterprise.flameeyes.is-a-geek.org> <20060706134939.6ecd7758@snowdrop.home> <44AD1843.1090707@gentoo.org> X-Mailer: Sylpheed-Claws 2.3.1 (GTK+ 2.8.19; i686-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: fdd4cf28-80be-48f7-97b1-950e2627e4bb X-Archives-Hash: db234dee8112d75546f1d05500e4e845 On Thu, 06 Jul 2006 16:03:47 +0200 Simon Stelling wrote: | Ciaran McCreesh wrote: | > Well, you're assuming that a) everyone's using a C compiler, b) that | > gcc has the slightest clue what it's doing, c) that the user has no | > problem using nasty hacks to regain control, d) that this | > information is only needed at compile time, e) that various gcc | > internal definitions won't change... You're adding a lot of | > complexity, and thus room for very weird breakages, to something | > that doesn't need it. | | as for... | | b) You kind of have to assume that when running a system that was | compiled from ground up with gcc Not really true. GCC can be quite happily wrong about what your CPU could support, so long as it's not told to use it. This happens with VIS, for example. | c) This is not about "regaining" control. Currently, users who want | to cross-compile are screwed and need nasty use.mask-hacks to not end | up with broken binaries. The inability to provide per-package CFLAGS | is a missing feature in portage, it's got nothing to do with this | issue. You can do it through bashrc. But then, if this is about working around Portage's annoying lack of sane cross compile handling, why not put a little effort into fixing it properly rather than a lot of effort into making the tree more complicated? -- Ciaran McCreesh Mail : ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list