Re: system libraries that need -R/path/

[Bruno Haible]

Albert Chin writes:
> The proposed macro will fail on Tru64 UNIX, AIX, and HP-UX.

This is a very inaccurate statement.

The AC_LIB_LINKFLAGS macro supports hardcoding library paths into executables
as far as the system supports it. The restrictions on particular systems will
of course be documented.

In the same way, you could accuse libtool for not being able to create
a shared library that contains code from a static library on Solaris/SPARC.
But this would be nonsense, because that limitation comes from the system, not
from libtool: The system linker gives an error "text relocation remains" when
the code from the static library has not been compiled with -KPIC. The fact
that some functionality that can be supported on Linux/x86 cannot be supported
on Solaris/SPARC doesn't make it a fatal libtool bug.

Back to AC_LIB_LINKFLAGS:

  - There are systems like very ancient SysV systems which don't have any
    rpath-hardcoding functionality at all. (Must have been the beginning of
    the shared library era.) On these systems, the AC_LIB_LINKFLAGS will
    have no effect, i.e. programs will compile like they do today.

  - There are systems like OSF/1 where AC_LIB_LINKFLAGS supports only one
    directory containing shared libraries to be hardcoded. This will be a
    documented limitation. If you don't like it, you're welcome to extend
    AC_LIB_LINKFLAGS in a way that respects the 7 goals set out in
    http://mail.gnu.org/archive/html/autoconf/2002-05/msg00124.html.
    I don't see a way how to do it.

  - The statement that the macros fail on AIX is wrong. You must have
    attempted to create shared libraries with some version of GCC that
    doesn't support it.

  - The macros fully support HP-UX. All tests pass on this platform. (Tested
    on HP-UX 10.20, with CC="cc -Ae -O" CFLAGS="" CXX="aCC -O".)

In summary, AC_LIB_LINKFLAGS works nicely across the wide range of modern
operating systems.

Bruno