HP-UX 11.00 and dlopen()

[libtool]

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 (address@hidden)