bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH] Improvements to relocatable


From: Bruno Haible
Subject: Re: [PATCH] Improvements to relocatable
Date: Sun, 30 Jul 2017 14:29:42 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-83-generic; KDE/5.18.0; x86_64; ; )

Hi Reuben,

Thanks for the work on this!

> > Patch 1 makes the default license in the files GPL, to avoid confusion;
> > Bruno agreed to this: http://lists.gnu.org/archive/html/bug-gnulib/2017-
> > 04/msg00013.html

Applied with modification: there was still one occurrence of the word 'Lesser'
left. Also, clarified in the ChangeLog entry that the copyright header is
being changed, not the license. The license is stated in modules/relocatable
and is not being changed.

> > Patch 2 adds Valgrind suppressions.

Applied with modification: Renamed build-aux/relocatable.supp to
lib/relocatable.valgrind, because we already have a number of lib/*.valgrind
files.

> > One open question is how bootstrap can
> > tell the user about these in the same way as configure.ac and Makefile.am
> > changes.

Yes, it's an open question. For the moment, there is no message, because
every package uses valgrind in a different way.

> > Patch 3 improves the documentation as outlined in http://lists.gnu.org/
> > archive/html/bug-gnulib/2017-04/msg00008.html

I've applied the documentation change. But the invocation of
AC_CONFIG_LIBOBJ_DIR is in the responsibility of the programmer, not of
gnulib, because
  1. gnulib-tool knows little about the package's directory structure,
  2. there can only be 1 invocation of AC_CONFIG_LIBOBJ_DIR.

> > Patch 4 changes the default to relocation being enabled; patch 5 changes
> > the default for ENABLE_COSTLY_RELOCATION to 1. In both cases the idea is
> > that the cost is negligible on GNU systems, and small on almost all systems
> > (Cygwin being the only exception I'm aware of).

Re patch 4: Should --enable-relocatable be the default?
There are three kinds of consumers of a GNU source package:
  - The distributors,
  - The package distributors (e.g. Mozilla, videolan.org).
  - The individual users.
Like it or not, but
  1. About 98% of the software a user is running was packaged by a distributor,
  2. The distributors don't like executables and libraries linked with -rpath.
     (Because of this, I had to add code to the 'havelib' module to not
     use "-rpath /usr/lib".)
If we make --enable-relocatable the default, all GNU packages that use the
'relocatable' module will get discussions with the distributors. And there are
many distributors! [1]
Therefore I would not do this.

Re patch 5: ENABLE_COSTLY_RELOCATION "allows libraries to be have been installed
with a different original prefix than the program". Who needs this?
  - Distributors don't need --enable-relocatable at all.
  - Package distributors create a single binary package; they use the same
    --prefix for all the parts of their package.
  - Most individual users do the same, because you get crazy when you use a
    different --prefix for each package.
So all in all, I think only few individual users need it, and when it's
associated with a cost (1. complex code, 2. runtime cost: accessing /proc),
I would not enable it.
On this one, I'm willing to discuss - if you can tell how this
ENABLE_COSTLY_RELOCATION would be useful for you?

Bruno

[1] https://repology.org/metapackage/coreutils/versions




reply via email to

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