This is the mail archive of the
mailing list for the GCC project.
Re: Installation proposal
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 27 Feb 2002 18:30:11 -0800
- Subject: Re: Installation proposal
> 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 email@example.com
CodeSourcery, LLC http://www.codesourcery.com