From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4410 invoked by alias); 17 Jan 2005 14:47:27 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 3967 invoked from network); 17 Jan 2005 14:46:32 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 17 Jan 2005 14:46:32 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0HEkUm8019211 for ; Mon, 17 Jan 2005 09:46:31 -0500 Received: from talisman.cambridge.redhat.com (talisman.cambridge.redhat.com [172.16.18.81]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0HEkUO29690; Mon, 17 Jan 2005 09:46:30 -0500 Received: from talisman.cambridge.redhat.com (localhost.localdomain [127.0.0.1]) by talisman.cambridge.redhat.com (8.13.1/8.12.10) with ESMTP id j0HEkTRE025857; Mon, 17 Jan 2005 14:46:29 GMT Received: (from rsandifo@localhost) by talisman.cambridge.redhat.com (8.13.1/8.12.10/Submit) id j0HEkSW1025856; Mon, 17 Jan 2005 14:46:28 GMT X-Authentication-Warning: talisman.cambridge.redhat.com: rsandifo set sender to rsandifo@redhat.com using -f To: Hans-Peter Nilsson Cc: Mark Mitchell , binutils@sources.redhat.com Subject: Re: PATCH: --sysroot-suffix References: <200501170322.j0H3MJWt031460@sirius.codesourcery.com> <20050117033833.GA31812@nevyn.them.org> <41EB3939.2010104@codesourcery.com> <20050117143236.GA21868@nevyn.them.org> From: Richard Sandiford Date: Mon, 17 Jan 2005 14:47:00 -0000 In-Reply-To: <20050117143236.GA21868@nevyn.them.org> (Daniel Jacobowitz's message of "Mon, 17 Jan 2005 09:32:37 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-01/txt/msg00169.txt.bz2 Daniel Jacobowitz writes: > Apple were interested in using it for native toolchains, however. Plus > the restriction is one of those things that is awkward to document. > Can you explain why there was a problem? I never tried it for native configurations, so I don't know for sure that there is a problem. But I was worried if we didn't have this restriction, people would expect passing --sysroot=/foo to a non- sysrooted toolchain to have exactly the same meaning as configuring with --with-sysroot=/foo. That isn't going to be true without further surgery because --with-sysroot affects the default search path. (see ld/genscripts.sh, for example.) But to be honest, the main blocker for me is that I don't really know what --sysroot is supposed to do on a non-sysrooted toolchain. If this patch does what's required, then great. I've no objection to removing the error. Richard