bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnulib] Re: relocatable packages


From: Bruno Haible
Subject: Re: [Bug-gnulib] Re: relocatable packages
Date: Wed, 9 Apr 2003 15:52:48 +0200 (CEST)

Hi Alexandre,

Thanks for the constructive feedback!

>  Bruno> The runtime penalty and size penalty are nearly zero on
>  Bruno> Linux (just one system call more when an executable is
>  Bruno> launched), and small on other systems (the wrapper
>  Bruno> program just sets an environment variable and execs the
>  Bruno> real program).
> 
> Is there any other justification to the --enable-relocatable
> option, other than avoiding this small penalty?  I'd find
> preferable that relocation be mandatory.  If you leave this as
> an options, packagers (e.g. people who build RPM package) will
> not use it

The reasons for not making --enable-relocatable the default are:

- On non-Linux platforms, we have wrapper executables, and it will
  look strange to people to have both 'foo' and 'foo.bin' installed.
  It might also confuse some prepared file lists (e.g. in *BSD
  binary packaging mechanisms).

- Even on Linux, it makes every executable ca. 4 KB larger.

- For --enable-relocatable to work reliably, a unique --prefix must be
  chosen by the installer. If a user does

       ./configure --enable-relocatable
       make ; make install
       mv /usr/local /old/local

  then installs new packages in /usr/local, the packages in /old/local
  will not run correctly because on some systems (including Linux)
  they will access the shared libraries in /usr/local before trying to
  look in /usr/local.

I hope that people will learn when to use --enable-relocatable by
themselves. For example, I don't think a Linux distributor should use
--enable-relocatable for anything installed in /usr - it would only
be bloat that makes the system slower.

> If packages are always built relocatable, then in many years we
> might reach the point where you can download a random RPM and
> install it in your account.

Yes that's my vision too.

>  Bruno> - to EXTRA_DIST
>  Bruno> alloca_.h alloca.c
>  Bruno> canonicalize.h canonicalize.c
>  Bruno> memmove.c
>  Bruno> relocatable.h relocatable.c
>  Bruno> relocwrapper.c
>  Bruno> setenv.h setenv.c unsetenv.c
>  Bruno> strerror.c
> 
> If these are the files which will be AC_LIBOBJed, then you might
> as well list the .h files in libfoo_a_SOURCES, and suppress the
> EXTRA_DIST.  .c files should be distributed automatically, just
> because they appear in a AC_LIBOBJ call.

Yes, I know, but I avoid AC_LIBOBJ because it does not everything well
(1. it does not perform the configure checks needed for the lib/foo.c
file, 2. it doesn't define HAVE_FOO is the function foo is available.)

>  Bruno> And the following also also necessary, once per
>  Bruno> Makefile.am that installs a program:
> 
>  Bruno> # Support for relocatability.
>  Bruno> RELOCATABLE_LIBRARY_PATH = $(libdir)
>  Bruno> RELOCATABLE_SRC_DIR = $(top_srcdir)/lib
>  Bruno> RELOCATABLE_BUILD_DIR = ../lib
>  Bruno> RELOCATABLE_CONFIG_H_DIR = ..
>  Bruno> @SET_RELOCATABLE@
> 
> This looks like the kind of things Automake would be able to
> output automatically with a bit of help from AC_RELOCATABLE.  Is
> there any other place where Automake support would be needed?

Yes I think the compilation flags for some C files could also be
inferred by automake. What I mean is that when I write

bin_PROGRAMS = ... xgettext ...

then I have to compile xgettext.c with

-DINSTALLDIR=\"$(bindir)\"

Similarly for pkglibdir instead of bindir etc. This could be
automated.

> An old project of mine that I haven't touched for months
> (http://heroes.sourceforge.net/), is relocatable too.  I'll
> summarize this here just to give a different view on relocation,
> but actually I don't think you'll find anything interesting to
> reuse.  

The technique for searching the current location (look through PATH if
argv[0] doesn't contain a slash) is basically the same.

> Another thing I wanted was the possibility to run the binary
> installed in the system, but change one of the files it uses
> using some user configuration.  I've found this very conveniant
> during development.

This is a different issue, not in the scope of --enable-relocatable.

> I compute these relative paths at configure time
> using the following macros 
>   http://www.gnu.org/software/ac-archive/htmldoc/relpaths.html
>   http://www.gnu.org/software/ac-archive/htmldoc/normpath.html

Well, I chose to compute them at run time because this requires the
minimal amount of changes to configure.ac and to the source code.
I don't force people to use new variables like RELATIVE_BINDIR etc.
Instead they continue to use BINDIR etc. and just add a few
'relocate()' calls here and there.

> Otherwise if it can't find the file
> and the user didn't help by setting a HEROES_PREFIX envvar

The --enable-relocatable mechanism is designed to work without
requiring any environment variables or "help from the user".

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]