This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]