Re: Using libtool for linking

[Ralf Wildenhues]

* Jason Curl wrote on Fri, Aug 17, 2007 at 01:29:36PM CEST:
> Bob Friesenhahn wrote:
>>
>> Perhaps the authors of libiberty do not expect that it will be used by 
>> anyone else.

I don't think so.

> Then this condition needs to be testable. I see two options:
> - Automatically disable shared libraries on this platform
> - Link statically from this library to our shared library

There are more options; see below.  FWIW, I typically use notation
that's the other way round, as I would call the situation "Link
statically to this library from our shared library".  Just to avoid
confusion.  ;-)

> There is no .la for this of course, I don't think it can be expected for it 
> to be installed just for the sake of libtool.

Indeed.  And IMHO it's libtool's job to cope with system libraries that
do not ship .la files, at the very least if they weren't created by
libtool.

> As for testing the situation, AC_CHECK_LIB makes me believe it will work. 

AC_CHECK_LIB checks whether you can link a program against a library,
not a library against a library.  Hint: try AC_CHECK_LIB with
CFLAGS=-fpie on GNU/Linux/x86_64 with a static library containing
non-PIC code.

> So, ideas how to work around this problem to achieve my goal?

I suppose going by Peter's suggestion is a good idea.  Otherwise read
on:

This libtool bug is a consequence of the setting(s)
  deplibs_check_method="pass_all"

in the libtool script.  You could try setting them to test_compile.
Report the inevitable bugs to bug-libtool, please, including the
exact Libtool version you used, and the output of `libtool --tag=TAG
--config', with TAG replaced, and of `libtool --debug --mode=link...',
i.e., --debug added to the failing link command.  Thanks.
(IIRC I fixed a couple of test_compile bugs in HEAD a while ago.)

FWIW, there has at one time been a long, heated debate around all this.
To really fix things, some work would need to be done (rather than
rehashing of old arguments).

Cheers,
Ralf