Re: INSTALL matters

[Bruno Haible]

About the topic how the installing person can tell configure where to find the
previously installed gmp, Neil Jerram wrote:
> > Even if you pass absolute filenames and '-rpath', on some systems,
> > the information written into the executable by the linker does not contain
> > sufficient information for choosing library A from /usr/lib (and not
> > /usr/local/lib) while at the same time choosing library B from 
> > /usr/local/lib
> > (and not /usr/lib).
> 
> I think you're saying here that the new gnulib macros don't work on all
> platforms.  Is that correct?

In the weird cases that you are mentioning (like /dir1/lib/ and /dir2/lib/
which each contain libA and libB, and the user asks to use /dir1/lib/libA.so
and /dir2/lib/libB.so), yes, there are platforms where this will not work.

But these are not the typical cases and not the common cases. In this case,
where the emphasis is on making the user's life easier, it is acceptable to
choose a solution that "works" only in 98% of the cases.

> >> This suggests a possibility, of automatically adding $prefix/include
> >> to CPPFLAGS and $prefix/lib to LDFLAGS.
> >
> > Yes. If I have installed gmp with the same --prefix option, then this
> > is needed and desired. Autoconf does not do it automatically.
> 
> But you are happy for this to require saying `--with-gmp-prefix=/opt'
> (or whatever) when configuring Guile, right?

I'm happy with any solution that minimizes the guesswork that the installing
person has to do.

> Now I'm confused.  I thought that doing what the new gnulib macros do
> (i.e. specifying full paths to the linker, and using rpath) means that
> cases like these _can_ be supported - at least on the platforms where
> the full paths are stored and respected.

These platforms are not the majority. The majority of platforms (including
glibc systems, Solaris systems) use ELF. ELF shared libraries store their
dependencies in the form of a directory path and basenames of libraries.
Example:

$ readelf -d /packages/gnu/lib/libmpfr.so

Dynamic section at offset 0x2e8ac contains 23 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libgmp.so.3]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000e (SONAME)                     Library soname: [libmpfr.so.1]
 0x0000000f (RPATH)                      Library rpath: [/packages/gnu/lib]
 ...

When I do

$ ldd /packages/gnu/lib/libmpfr.so
        linux-gate.so.1 =>  (0xffffe000)
        libgmp.so.3 => /packages/gnu/lib/libgmp.so.3 (0xf7ee8000)
        libc.so.6 => /lib/libc.so.6 (0xf7d79000)
        /lib/ld-linux.so.2 (0xf7f4c000)

the absolute filename /packages/gnu/lib/libgmp.so.3 is already the result
of the search of the 'NEEDED' file in the 'RPATH'.

So, what you view as a problem in the gnulib macros is a system file format
limitation.

> > The difference that I meant is when I use the same --prefix for a couple of
> > related packages. Suppose my goal is to install 'guile'. I learn that it 
> > needs
> > 'gmp', so I download and install that, with the same expected prefix. Then I
> > install guile with the same prefix and it refuses to acknowledge the 
> > previously
> > installed packages, that it frustrating.
> 
> OK, so you _do_ think that $prefix/lib should be added to LDFLAGS by
> default, and $prefix/include to CPPFLAGS.

Yes. This makes most sense for the installing user.

> Is there an autoconf macro 
> to do that?  If there is, does it support a ./configure option for
> disabling it, for any cases where it isn't wanted?

Good points :-) You are welcome to ask for this on the autoconf list; I
support your idea.

> Overall, then...
> 
> 1. I think I agree now that using the gnulib macros to provide
> --with-xxx-prefix options is a good idea.  I'm nervous about adding a
> build dependency on so much new code (e.g. AC_LIB_LINKFLAGS_BODY is
> nearly 500 lines long), but I suppose that must be the right thing to
> do for the GNU project as a whole, and that if there are problems
> we'll just work through them.

The AC_LIB_LINKFLAGS_BODY is maintained for a couple of years already.
Most problems must have been shaken out already:
  
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=history;f=m4/lib-link.m4;h=21442033c87bd65912d4337d2f3fe686da708e01;hb=68dfc9591e97db34b5ba693da028ff1f356a12b7

> 2. There is a lot of subtlety involved in understanding how these
> options work, and what can be relied on on different platforms, and
> explaining that to users; and none of that is Guile-specific.  So
> rather than explaining bits of this in Guile's FAQ/web pages/whatever
> it would be better to point to a reliable place where it's explained
> more generally.  Is there already such a place?  If not, any
> suggestions for where it should be?  I'm happy to draft an initial
> text, if nothing already exists.

The doc is also in gnulib, at
  
http://www.gnu.org/software/gnulib/manual/html_node/Searching-for-Libraries.html
(generated from gnulib/doc/havelib.texi). It's explained in some
detail, but more from the perspective of the developer than from the
view of the user.

Bruno