From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23319 invoked by alias); 4 Mar 2003 21:32:51 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 23306 invoked from network); 4 Mar 2003 21:32:51 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 4 Mar 2003 21:32:51 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18qLuy-00029x-00; Tue, 04 Mar 2003 17:33:52 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18qK1c-0001Xz-00; Tue, 04 Mar 2003 16:32:36 -0500 Date: Tue, 04 Mar 2003 21:32:00 -0000 From: Daniel Jacobowitz To: Alexandre Oliva Cc: Hans-Peter Nilsson , gcc-patches@gcc.gnu.org Subject: Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken Message-ID: <20030304213235.GA5818@nevyn.them.org> Mail-Followup-To: Alexandre Oliva , Hans-Peter Nilsson , gcc-patches@gcc.gnu.org References: <20030222035554.GA15132@nevyn.them.org> <200302220412.h1M4CYO1021431@ignucius.axis.se> <20030222042505.GA15670@nevyn.them.org> <20030304192456.GA14297@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00382.txt.bz2 On Tue, Mar 04, 2003 at 06:17:21PM -0300, Alexandre Oliva wrote: > On Mar 4, 2003, Daniel Jacobowitz wrote: > > > On Tue, Mar 04, 2003 at 04:19:11PM -0300, Alexandre Oliva wrote: > >> On Feb 22, 2003, Daniel Jacobowitz wrote: > > >> > The change was that when you run gcc > >> > from outside the installation prefix, nothing inside the installation > >> > prefix will be searched. > > >> Not even the original (unrelocated) installation prefix? This sounds > >> wrong to me. If I read you correctly, this means that the sys-root > >> isn't searched during the GCC build process. Is this the effect of > >> your change? If so, I don't agree it's the right thing to do. > > > In theory it could mean that, but there's something else involved that > > we discussed: we only relocate the sysroot if (the sysroot was inside > > the prefix and) the new directory would exist. > > Note I'm not worried about sysroot relocation atm. I'm worried about > GCC not searching the prefix it was configured for before it was > installed. The need for the explicit sys-includes in the top level > seems to indicate it won't search that directory when started from the > build tree. Assuming we have it consistent, I assume the same applies > to sys-root/usr/include. I do think that, if GCC can't find the > directory it's looking for in the relocated prefix (or, as it happens, > in the build tree), it should look at the install prefix. > > Otherwise, if you build and install binutils, then part of gcc, then > newlib, then all of gcc in the same prefix, the gcc build would not > find the installed binutils and newlib, which it has always done, and > should, IMHO, still do. It ought to work correctly. To be honest, I can't be more specific; there are too many active relocation schemes in GCC for me to figure out. > > I believe that (even though both were configured for > > /opt/manufacturer), the one in /opt/manufacturer-old should not search > > there and autoconf checks for version2.h should fail. > > Agreed. If it finds sys-(include|root) in the relocated tree, it > should not look for it in the original prefix. If this is the only > thing you changed, and it still looks in the original prefix if it > can't find the include *directory* in the relocated prefix, I'm happy > with it. For sysroot it does this on the basis of whether it can find the sysroot. For include paths it doesn't; it's not done on a per-directory basis. We already specify the directory that newlib ought to be installing its headers to as an -isystem; I think we have for a long time. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer