Re: Installation proposal

[Alexandre Oliva <aoliva@redhat.com>]

On Feb 27, 2002, Mark Mitchell <mark@codesourcery.com> wrote:

> 1. Create a subdirectory of the objdir called "install".

> 2. Treat install as if it were the final prefix during building --
>    put everything in there.  That means that there will be directories
>    like "install/bin", "install/lib", and so forth.  So, "make" would
>    just drop everything in these directories.

> 3. At install time, run a single script which copies everything in
>    install into prefix.

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.  By doing an
installation with something as simple as cp -R or the tar or cpio
equivalents, you lose the ability to modify exec_prefix at all, even
if it follows the current requirements.

Not that I find this extremely important, but I thought I point it out
so that we may a conscious decision regarding breaking backward
compatibility with a feature that probably nobody uses (namely
exec_prefix from $prefix/foo at build time to $prefix/bar at install
time).

> 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.

> 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 (because prefix has
to be a full pathname; relative pathnames are not rejected outright as
they should, but they don't work).

Also, you don't want to have installed programs looking for stuff in
the build tree; that's a security threat.  But that's what you'll get
if you configure the default prefix as something within the build
tree.  Also, on a number of some systems, when you don't specify
dynamic search paths when linking an executable or a shared library,
they'll use -L flags or the location of libraries at build time as the
default search path for libraries which, again, is a security threat.

Modifying the configured prefix is an absolute no-no.  Doing a DESTDIR
install is definitely a much saner approach, even though it doesn't
totally defeat the security threat related with default search paths.
To do that, you have to use different linking flags on different
platforms, when building both libraries and executables linking with
them, and you sometimes have to resort to relinking at install time,
as I wrote in another message in this thread.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer