From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3492 invoked by alias); 28 Feb 2002 02:30:47 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 3408 invoked from network); 28 Feb 2002 02:30:43 -0000 Received: from unknown (HELO localhost.localdomain) (66.60.148.227) by sources.redhat.com with SMTP; 28 Feb 2002 02:30:43 -0000 Received: from warlock.codesourcery.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g1S2UBB16885; Wed, 27 Feb 2002 18:30:11 -0800 Date: Wed, 27 Feb 2002 18:33:00 -0000 From: Mark Mitchell To: Alexandre Oliva cc: "gcc@gcc.gnu.org" Subject: Re: Installation proposal Message-ID: <18220000.1014863411@warlock.codesourcery.com> In-Reply-To: X-Mailer: Mulberry/2.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2002-02/txt/msg01751.txt.bz2 > This will change the requirements imposed on exec_prefix. According > to the GNU Coding Standards, the user should be able to modify prefix > and exec_prefix at install time. Currently, GCC already fails to > follow this recommentation: it depends on exec_prefix being a > sub-directory of prefix, and on the relative pathname from exec_prefix > to prefix not changing from build to install time. Interesting. If we keep that requirement, it actually makes things easier: you can use that same relative in the "install" directory, and then using exec_prefix should still work. >> 3. We would test that our installations are really location-independent, >> which they supposedly are. > > Not really. At least not cross toolchains that use a shared glibc as > the C library, because glibc's libc.so is a linker script that > references full pathnames into the install tree. Yet another problem > about which we must make a conscious decision. Hmm, yes. If we have post-install hooks (already pointed out as necessary for install-info), then I suppose we could fix this. >> We can just have the top-level configure set the prefix for all of the >> child configures to "install". > > And now you can't move your build tree any longer Not a big deal, surely. > Also, you don't want to have installed programs looking for stuff in > the build tree; that's a security threat. Yes, this is a big deal. Of course, this implies that the location-independence isn't working, or that we're falling back to $prefix when we can't find ourselves. Which might be reasonable. This seems like a serious issue. == Here are my conclusions: 1. You and Jim have persuaded me that this is complicated. 2. In fact, you've persuaded me that it is far too complicated. We support too many different build and installation modes. We use too much goo to accomplish that. The goo has hardened over the years to the point where it is hard to perturb it at all, even in such a way as to make the eventual result much simpler. 3. However, if I change things, I will probably be dealing with email from someone who wants to use exec_prefix when building a Candian cross to a PDP-11 using glibc's full-pathname linker script for the next six weeks. 4. Therefore, I shan't do anything. We'll just keep doing "-B... -I... -L..." with lots of horrible logic scattered around the tree to figure out whether we need "../../.." or just "../..", keep it hard to run our tests by hand (just what do I have to set LD_LIBRARY_PATH to again?), and so forth. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com