While running ./configure for libtool 1.4 on a hppa1.1-hp-hpux11.00 system: ... checking for dlfcn.h... yes ... checking if libtool supports shared libraries... yes checking for dlopen in -ldl... no checking for dlopen... yes checking whether a program can dlopen itself... yes checking whether a statically linked program can dlopen itself... no The presence of dlopen is tested for from the following libtool.m4 snippet: AC_CHECK_LIB(dl, dlopen, [lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-ldl"], [AC_CHECK_FUNC(dlopen, lt_cv_dlopen="dlopen", [AC_CHECK_FUNC(shl_load, lt_cv_dlopen="shl_load", [AC_CHECK_LIB(svld, dlopen, [lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-lsvld"], [AC_CHECK_LIB(dld, shl_load, [lt_cv_dlopen="dld_link" lt_cv_dlopen_libs="-dld"]) ]) ]) ]) ]) Also, dlopen() is present in 64-bit HP-UX 11.00. However, for 32-bit systems (like the one being tested here), you need a patch (PHSS_22514) to get dlopen. This system has PHSS_22478 installed (predecessor patch to PHSS_22514). From the list of bugs fixed in PHSS_22514 (after PHSS_22478): - JAGac39834: Severity: 6 32 bit dlopen/dlsym calls can't be used on 1.1 systems So, I did the following: $ cat a.c char dlopen(); int main () { dlopen(); } $ cc -Ae a.c $ nm a.out dlopen | |undef |code | dlopen | 10000|uext |stub | I think the dlopen above comes from /usr/lib/libdld.sl. So, how about we *force* shl_load on at least HP-UX 11.00 32-bit? Or maybe we should check for shl_load before dlopen (which would have the effect of not using dlopen on HP-UX at all)? We don't have to worry about 10.20 because it doesn't have dlopen(). Should we consider forcing shl_load for HP-UX 11.00 64-bit as well? -- albert chin ([EMAIL PROTECTED]) _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool