Pete Naylor pete@geckoworks.com writes:
Much thanks - this led me to the realization that the runtime linker wasn't able to find liboop when configure was calling conftest. Seems that GNU autoconf doesn't necessarily deal with shared libraries very well in Solaris.
autoconf doesn't know much about -R flags. However, lsh's configure script tries to figure it out. First, it adds -L-flags from your --with-lib-path argument, and puts the directories on the RPATH_CANDIDATE_DIRS list. It also looks at uname to figure out what the "-R"-flag is called on your system. Next, from configure.ac:
AC_CHECK_LIB([oop], [oop_sys_new],, [AC_MSG_ERROR([liboop is missing. Get liboop from http://www.liboop.org])])
LSH_RPATH_FIX
The first macro expands into a linking test, and adds an -l flag. The next macro tries do compile and run a dummy test program, and if that fails (typically because the new -l flag made the linker link the test program with some library that isn't found at runtime), it tries to add -R options from using the directories in RPATH_CANDIDATE_DIRS.
These tricks have worked for me (on Solaris), so if it doesn't work for you I'd like to see a full bug report, including the config.log.
I dropped the library and include path options to configure and instead put all that info in my LDFLAGS and CPPFLAGS environment variables - no more problems.
If you know exactly what your doing, setting those variables directly is the most robust way. However, it's better to put them on configure's command line,
./configure LDFLAGS=...
rather than
LDFLAGS=... ./configure
because otherwise they will be lost whenever configure is rerun, typically by ./config.status --recheck is run. (Variables on the command line are supported since autoconf 2.5something, it won't work with configurescripts created by autoconf-2.13).
Regards, /Niels