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
