Re: INSTALL matters

[Neil Jerram]

Bruno Haible <address@hidden> writes:

> Hi,

Hi Bruno,

I'm trying to win a prize here for most delayed email response :-)

Seriously, thanks for raising this.  This issue, and the related (in
my mind) one about having multiple copies of a library installed in
different places, keep cropping up now and then, so it would be great
to resolve them.

First, a couple of assumptions: as far as I understand,

- in general, there is no portable way of telling the compiler and
  linker to look in one set of prefixes for library A, and in a
  different set of prefixes for library B

  specifically, therefore, if you have multiple versions of libraries
  installed in /usr/lib and /usr/local/lib (or /opt/lib, whatever...),
  there's no way of reliably getting the /usr/lib version of library A
  and the /usr/local/lib version of library B

- worse (at least with the GNU toolchain), if you have multiple
  versions of library A in /usr/lib and /usr/local/lib, you can't get
  a consistent build at all, because gcc prefers /usr/include when
  looking for headers, but ld and ld.so prefer /usr/local/lib when
  linking.  (Or perhaps the other way round.  I haven't rechecked the
  detail for this email, but I'm sure that they were inconsistent when
  I last checked.)

If those are wrong, my following comments may be wrong too.

> I'm trying to install guile-1.8.5 on MacOS X 10.5. I've already installed
> gmp-4.2.2 with the same --prefix option as I use for guile,

This suggests a possibility, of automatically adding $prefix/include
to CPPFLAGS and $prefix/lib to LDFLAGS.  But see below.

> and the configuration
> bails out nevertheless:
>
> $ ./configure --prefix=$HOME/data/local-macos CPPFLAGS=-Wall
> ...
> checking for __gmpz_init in -lgmp... no
> configure: error: GNU MP not found, see README
>
> guile's README has two paragraphs about this topic. Both are less than
> helpful:
>
>   - The first paragraph says that the installer should consider -I options,
>     but does not say how to pass them (CFLAGS? wrong! CPPFLAGS!), and moreover
>     does not even mention that LDFLAGS need to be set as well (for -L and
>     rpath related options).

Completely agree that this is not helpful enough.  I'll propose an
update once we're agreed on the overall picture.

>   - The second paragraph recommends to rebuild GCC to match --prefix. This
>     is just gross. It takes a novice user half a dozen attempts to find out
>     the right set of configure options for building gcc, and then the build
>     itself takes 10 hours and requires 500 MB of swap space.

The README doesn't recommend this; it says that it is a "convenient"
option.

In some specific contexts - e.g. an admin setting up a box with all
3rd party software under /opt - I think that this would indeed be a
convenient option.

I agree, though, that those contexts are unlikely to apply to most
people, and the README text should be clearer about that.  I'll
propose an update.

> Can you please add an option --with-gmp-prefix or --with-gmp, with which the
> installer can *easily* specify where he has installed GMP?
>
> Precedents:
> - mpfr-2.3.1 has
>   --with-gmp=DIR          GMP install directory
>   --with-gmp-include=DIR  GMP include directory
>   --with-gmp-lib=DIR      GMP lib directory
>   --with-gmp-build=DIR    GMP build directory
> - cln-1.2.2 has
>   --with-gmp[=DIR]        use external low-level functions from GNU MP
>                           (installed in prefix DIR) [default=yes].
>
> Similarly, can you please add an option --with-readline-prefix or
> --with-libreadline-prefix, with which the installer can *easily* specify where
> he has installed GNU readline?
>
> Precedents:
> - GNU clisp 2.44.1 has
>   --with-libreadline-prefix[=DIR]  search for libreadline in DIR/include and 
> DIR/lib
>   --without-libreadline-prefix     don't search for libreadline in includedir 
> and libdir
> - gnulib has a readline.m4 autoconf macro that provides
>   --with-libreadline-prefix[=DIR]  search for libreadline in DIR/include and 
> DIR/lib
>   --without-libreadline-prefix     don't search for libreadline in includedir 
> and libdir

I would prefer to document really clearly how to use CPPFLAGS and
LDFLAGS, rather than adding these options.

I don't like these options because they seem bogus to me.  Providing
`--with-libreadline-prefix' makes it sound like the build and runtime
will look specifically (and only) in that prefix when building/linking
readline, and in the default places for other libraries.  And that is
not true, because there is no way of doing that.

Using CPPFLAGS and LDFLAGS is better, in my view, because it
corresponds to what the toolchain can actually do - i.e. search in one
global set of places for all headers, and in one global set of places
for all libraries.

Therefore I would like to document the proper use of CPPFLAGS and
LDFLAGS, explain when these are needed, and also explain the problem
with having multiple library versions installed.

Now coming back to the point above about automatically adding
$prefix/include to CPPFLAGS and $prefix/lib to LDFLAGS...  It's an
interesting idea, but I'm sure that it would cause unwanted build
behaviour for some people, and it should be trivial (given proper
documentation) for people who _do_ want this to set their CPPFLAGS and
LDFLAGS; so on balance I don't think we should do this.

> As an installer, I'm not going to spend time trying to see which LDFLAGS I 
> need
> to set for a package to recognize the libraries that I have installed. I 
> expect
> the package to do this by itself.

I don't get this last paragraph.  You have to add a path either to
--with-xxx-prefix or to CPPFLAGS and LDFLAGS, so what difference does
it make?

Many thanks again for your input on this.

Regards,
        Neil