httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Ralf S. Engelschall)
Subject Re: building with mod_so
Date Sat, 04 Apr 1998 17:43:53 GMT

In article <35266799.F1CC5C15@Golux.Com> you wrote:
> Ralf S. Engelschall wrote:
>> A few facts:
>> 1. mod_so cannot be used under HP/UX because this system
>>    has no dlopen() function. So, the definitive list of supported platforms is
>>    in Configuration.tmpl.  Any other platform which has dlopen() could be
>>    used, but only because...

> Maybe a mod_so.module file could be created that points this
> out at Configure time?

Hmmmm... not with the current Configure, because the shared object support is
done after the general compiler/linker flag determination, but before the
modules get checked for .module etc. But we can print at least the definitive
static list of supported and unsupported platforms in the error message. It
would be the list from Configuration.tmpl, of course. 

To make the situation clear, currently we have the following three types of

   1. Out-of-the-box supported platforms
      (they all have dlopen() and we already know
      the compiler and linker flags):
      - Linux
      - FreeBSD
      - Solaris
      - SunOS
      - IRIX
      - OSF1
      - UnixWare

   2. Supported platforms through Perl fallback strategy: 
      (they have dlopen() and we guess the compiler and linker flags from Perl
      if present and if Perl already uses its DynaLoader variant which uses
      - Usually all SVR4 derivates because they usually have
        dlopen() but we still don't know the flags

   3. Entirely unsupported platforms
      - HP-UX (because no dlopen)
      - Ultrix (because no dlopen?)
      - AIX (has dlopen and we know the horrible mass of flags and 
             hacks but nevertheless I'd resolver problems when I
             wanted to add DSO suppport: See my posting in new-httpd
             some times ago titled "[UNFINISHED] ... AIX ...")
                                       Ralf S. Engelschall

View raw message