httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Ralf S. Engelschall)
Subject Still existing problems w/ shared object support
Date Tue, 10 Mar 1998 09:56:34 GMT

Just FYI and perhaps someone has good ideas and want to solve it. We have
still the following problems with shared library support:

- The Configure script lacks support for building mod_proxy and
  mod_example as shared objects. Especially for mod_proxy this
  would be very useful because it not always needed and is a huge
  module. In theory this is simple: Instead of creating a
  libproxy.a with "ar" we create a with "ld". But in
  practice we had to fight with the Configure script :-(
  => The Configure script has to be enhanced to support this
     or at least a check has to be added to make sure
     mod_example and mod_proxy are not built with SharedModule

- The good old mime_find_ct() cross-call from mod_proxy to
  mod_mime makes heavy problems also for shared object support.
  Because when we've fixed the above problem mod_proxy can be
  build as a shared object, but only if mod_mime is then compiled
  statically (AddModule). On the other hand as long as mod_proxy
  is left out, mod_mime can be compiled as a shared object. But
  when mod_proxy is in with AddModule mod_mime again has to be
  compiled statically. In one word: The dependency makes the
  indiviual usage of "SharedModule" a problem.
  => Not easy to fix. I would recommend to either try to
     avoid the mime_find_ct() call in mod_proxy at all or at put
     the stuff into the core of Apache. Or at least we have to
     state that mod_mime always has to be compiled statically if
     mod_proxy is present - which is another ugly special case

- One can still use "SharedModule" for mod_so itself which is
  invalid because of bootstrapping.
  => A check has to be added to Configure

- The usage of SharedModule anywhere implies the usage of mod_so. 
  => A check has to be added to Configure

Any comments?
                                       Ralf S. Engelschall

View raw message