INSTALL matters

INSTALL matters

[Bruno Haible]

Hi,

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, 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).

  - 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.

Less than helpful, really.

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

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.

Bruno

Re: INSTALL matters

[Neil Jerram]

Bruno Haible <bruno@clisp.org> 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

Re: INSTALL matters

[Bruno Haible]

Hi Neil,

Neil Jerram wrote in reply to
<http://lists.gnu.org/archive/html/bug-guile/2008-05/msg00012.html>:
> This issue, and the related (in
> my mind) one about having multiple copies of a library installed in
> different places

Having multiple copies of a package installed in different places is
the most normal thing of the world. That's what --prefix is for.

> 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

There is. It consists in passing absolute file names for .h and .a or .so
files to the linker. If the input you have is a _set_ of of prefixes,
this means you need to search for the library in the same way as the
compiler or linker would do, and then pass the absolute file names to the
compiler or linker.

It is a bit far-fetched, but the mentioned macros in gnulib actually do this.

Without extra efforts, however, your statement is correct.

>   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

Correct. 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).

> - 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.

This is a problem on some BSD systems, IIRC. Also one specific GCC release
had this problem on Linux systems, a couple of years ago, and it was fixed
in the next GCC release. So I've come to view this as an inconsistency in
the GCC installation. The workaround to this situation is to never use
/usr/local, but rather pass a different --prefix always.

> > 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.

Yes. If I have installed gmp with the same --prefix option, then this
is needed and desired. Autoconf does not do it automatically.

> > 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.

Thanks.

> >   - 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.

We must have different interpretations of the term "convenient" :-)

> 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 don't think so. The users of this admin will wonder why their programs
behave differently when built with GCC than when built with the vendor's
compiler. (The reason would be that GCC links with different versions of
thirs-party libraries.)

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

That would be fine with me as well. The installer can be expected to
look into the README and INSTALL files and apply the instructions found
there.

> 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

It is correct that the option does not mean "hey configure, please
look for libreadline *exactly* here". It means "hey configure, I have
installed libreadline here".

Yes there are weird cases which cannot be supported, like the case
with libraries A and B in both /usr and /usr/local, which you mentioned
before. But the majority of the cases is not so weird, and in these
cases the --with-...-prefix options are helpful.

> 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.

I find a configure option better, because when the user installs a
package, he's not thinking at the level of linker details, but rather
"I have installed gmp here. Now how do I tell mpfr or guile about it?"

> 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.

Fine with me, if following this documentation yields a working build.

> 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.

Before I came to use --with-...-prefix options, I used CPPFLAGS and
LDFLAGS like you say. And quite often, the build failed because
  - I had not been aware of all dependencies before building the package, or
  - I had used LDFLAGS="-L/opt/gnu", rather than LDFLAGS="-L/opt/gnu/lib",
    (Simple typo/thinko, but frustrating anyway.)
  - I had used LDFLAGS="-L/opt/gnu/lib" but the build needs the 64-bit libraries
    so I should have used LDFLAGS="-L/opt/gnu/lib64".

The --with-...-prefix options do reduce frustration in these cases.

> > 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?

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.

I know that some of these problem come from the fact that GNU does not have
a package registry or package dependency tracking tool. That's actually good
because it gives much more freedom than 'rpm' or 'dpkg' do. But when a package
considers a dependency to be absent when it's actually present where you would
expect it, this needs correction IMO.

Bruno

Re: INSTALL matters

[Neil Jerram]

Bruno Haible <bruno@clisp.org> writes:

> Hi Neil,
>
> Neil Jerram wrote in reply to
> <http://lists.gnu.org/archive/html/bug-guile/2008-05/msg00012.html>:
>> This issue, and the related (in
>> my mind) one about having multiple copies of a library installed in
>> different places
>
> Having multiple copies of a package installed in different places is
> the most normal thing of the world. That's what --prefix is for.

OK...

>> 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
>
> There is. It consists in passing absolute file names for .h and .a or .so
> files to the linker. If the input you have is a _set_ of of prefixes,
> this means you need to search for the library in the same way as the
> compiler or linker would do, and then pass the absolute file names to the
> compiler or linker.
>
> It is a bit far-fetched, but the mentioned macros in gnulib actually do this.

Thanks for explaining.  I've seen these macros in gnulib now.

> Correct. 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?

>> - 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.
>
> This is a problem on some BSD systems, IIRC. Also one specific GCC release
> had this problem on Linux systems, a couple of years ago, and it was fixed
> in the next GCC release. So I've come to view this as an inconsistency in
> the GCC installation. The workaround to this situation is to never use
> /usr/local, but rather pass a different --prefix always.

OK, that's good news.  After looking at the latest GCC and binutils
docs, I agree that this old issue seems to be fixed now.  (-I and -L
directories are now always searched before the system-standard ones.)

>> > 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.
>
> 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?

>> 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 don't think so. The users of this admin will wonder why their programs
> behave differently when built with GCC than when built with the vendor's
> compiler. (The reason would be that GCC links with different versions of
> thirs-party libraries.)

In any case, this debate isn't at all Guile-specific; more on that
below.

>> 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
>
> It is correct that the option does not mean "hey configure, please
> look for libreadline *exactly* here". It means "hey configure, I have
> installed libreadline here".
>
> Yes there are weird cases which cannot be supported, like the case
> with libraries A and B in both /usr and /usr/local, which you mentioned
> before. But the majority of the cases is not so weird, and in these
> cases the --with-...-prefix options are helpful.

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.

>> 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.
>
> I find a configure option better, because when the user installs a
> package, he's not thinking at the level of linker details, but rather
> "I have installed gmp here. Now how do I tell mpfr or guile about it?"

OK, I agree now that that makes sense.

> Before I came to use --with-...-prefix options, I used CPPFLAGS and
> LDFLAGS like you say. And quite often, the build failed because
>   - I had not been aware of all dependencies before building the package, or
>   - I had used LDFLAGS="-L/opt/gnu", rather than LDFLAGS="-L/opt/gnu/lib",
>     (Simple typo/thinko, but frustrating anyway.)
>   - I had used LDFLAGS="-L/opt/gnu/lib" but the build needs the 64-bit libraries
>     so I should have used LDFLAGS="-L/opt/gnu/lib64".
>
> The --with-...-prefix options do reduce frustration in these cases.
>
>> > 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?
>
> 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.  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?

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.

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.

(Ludovic, do you have a view on all this?  Any one else?)

Many thanks again for your input on this stuff.

Regards,
        Neil

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

Re: INSTALL matters

[Neil Jerram]

Bruno Haible <bruno@clisp.org> writes:

> 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.

I agree; I just wanted to make sure that I fully understood.

>> 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.

And I see now that havelib does this.

>> 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.

OK, but I'll wait for a case (if any) where it's needed.

> 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
[...]
> 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.

Many thanks for all your input on this subject, Bruno.  I've applied
your suggestions to Guile's master branch (which will become the next
stable release series, 2.0.x):

http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=39b94fee4304d56babf5bd62e10c5786a79f4389
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=a89cafc0562942680db63fe8ddf89f466ba2f7af

If you have any further comments on this, I'd be happy to hear them.

Regards,
        Neil