view doc/relocatable.texi @ 17363:5a51fb7777a9

sys_select, sys_time: port 2013-01-30 Solaris 2.6 fix to Cygwin Problem reported by Marco Atzeri in <http://lists.gnu.org/archive/html/bug-gnulib/2013-03/msg00000.html>. * lib/sys_select.in.h [HAVE_SYS_SELECT_H && _CYGWIN_SYS_TIME_H]: Simply delegate to the system <sys/select.h> in this case too. Also, pay attention to _GL_SYS_SELECT_H_REDIRECT_FROM_SYS_TIME_H only if OSF/1, since otherwise Cygwin breaks, and it doesn't seem to be needed on Solaris either. * lib/sys_time.in.h [_CYGWIN_SYS_TIME_H]: Simply delgate to the system <sys/time.h> in this case.
author Paul Eggert <eggert@cs.ucla.edu>
date Tue, 19 Mar 2013 09:08:47 -0700
parents 64131ac8b004
children
line wrap: on
line source

@node Enabling Relocatability
@section Enabling Relocatability

It has been a pain for many users of GNU packages for a long time that
packages are not relocatable.  It means a user cannot copy a program,
installed by another user on the same machine, to his home directory,
and have it work correctly (including i18n).  So many users need to go
through @code{configure; make; make install} with all its
dependencies, options, and hurdles.

Red Hat, Debian, and similar package systems solve the ``ease of
installation'' problem, but they hardwire path names, usually to
@file{/usr} or @file{/usr/local}.  This means that users need root
privileges to install a binary package, and prevents installing two
different versions of the same binary package.

A relocatable program can be moved or copied to a different location
on the file system.  It is possible to make symlinks to the installed
and moved programs, and invoke them through the symlink. It is
possible to do the same thing with a hard link @emph{only} if the hard
link file is in the same directory as the real program.

To configure a program to be relocatable, add
@option{--enable-relocatable} to the @command{configure} command line.

On some OSes the executables remember the location of shared libraries
and prefer them over any other search path.  Therefore, such an
executable will look for its shared libraries first in the original
installation directory and only then in the current installation
directory.  Thus, for reliability, it is best to also give a
@option{--prefix} option pointing to a directory that does not exist
now and which never will be created, e.g.@:
@option{--prefix=/nonexistent}.  You may use
@code{DESTDIR=@var{dest-dir}} on the @command{make} command line to
avoid installing into that directory.

We do not recommend using a prefix writable by unprivileged users
(e.g.@: @file{/tmp/inst$$}) because such a directory can be recreated
by an unprivileged user after the original directory has been removed.
We also do not recommend prefixes that might be behind an automounter
(e.g.@: @file{$HOME/inst$$}) because of the performance impact of
directory searching.

Here's a sample installation run that takes into account all these
recommendations:

@example
./configure --enable-relocatable --prefix=/nonexistent
make
make install DESTDIR=/tmp/inst$$
@end example

Installation with @option{--enable-relocatable} will not work for
setuid or setgid executables, because such executables search only
system library paths for security reasons.  Also, installation with
@option{--enable-relocatable} might not work on OpenBSD, when the
package contains shared libraries and libtool versions 1.5.xx are used.

The runtime penalty and size penalty are negligible on GNU/Linux (just
one system call more when an executable is launched), and small on
other systems (the wrapper program just sets an environment variable
and executes the real program).