[Top][All Lists]
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Bug-gnulib] Re: relocatable packages,
Bruno Haible <=