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