Pete Naylor <[EMAIL PROTECTED]> 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
_______________________________________________
lsh-bugs mailing list
[EMAIL PROTECTED]
http://lists.lysator.liu.se/mailman/listinfo/lsh-bugs
