Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Tue, 7 Mar 2000 21:23:11 +0100
From: "Ralf S. Engelschall" <rse@engelschall.com>
To: new-httpd@apache.org
Subject: Re: mod_so in Apache 2.0
Message-ID: <20000307212311.A27341@engelschall.com>
Reply-To: rse@engelschall.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Organization: Engelschall, Germany.


In article <20000307192747.A24791@schumann.cx> you wrote:

> [...]
> We should probably teach mod_so to use libltdl, so we can get rid of this
> platform-dependent dynamic loading crap.
> 
> What do you guys think? 
> 
> [FYI: libltdl supports various interfaces (Solaris, Linux, *BSD, HP-UX, 
> Win16/32, BeOS, GNU DLD, AIX?), and can be included under the Apache license
> due to an extremly cool licensing scheme.]

Although I'm a fan of GNU libtool and use it myself in all my library
packages, I want to vote -0 for both the old stuff and libltdl in
Apache. Why? Because the old stuff is IMHO not clean enough to survive
the future and libltdl is tight to libtool and libtool is for (don't
say "haha")... DSO _libraries_ and not DSO modules. What? Yes, you read
correctly: I distinguish between those two DSO-types.

- RSE def. of "DSO Library":
  A DSO library is a _passive_ piece of code which is _implicitly_
  linked into the address space of a program by the Unix run-time linker.

- RSE def. of "DSO Module":
  A DSO module is an _active_ piece of code which is _explicitly_
  linked into the address space of a program by the program itself.

So what? The point is that libtool does a great job making the horribly
unportable way of dealing with DSO libraries visually portable. That
starts by finding PIC compiler flags, goes over fiddling around with
version symlinks (.so.1.2.3 -> .so, etc.) and ends by the abstraction
library libltdl for loading those DSO libraries manually. And its
obvious that a DSO library can be treated also as a DSO module, of
course. So its clear that one _could_ use libtool/libltdl also for
Apache modules. But that would be like using Emacs for writing text or
buying a car to listen to the radio. 

For dealing with DSO modules one usually need just approx. 20% of
libtool's functionality. Additionally libtool doesn't provide some
features which would be nice for an application which heaviliy counts
on DSO modules and has lots of them (for instance it is nasty to slowly
execute a large 110KB shell script on _every_ module-related compile
command in a source tree; it's nasty that the installed modules have
additional meta files which clutter the installation tree [sorry, I'm
also a optical perfectionist]; etc.).

For these reasons I currently write a new DSO package for a forthcoming
DSO-based package, which is very very similar to GNU libtool, but
focuses exclusively on dealing with DSO _modules_. Unfortunately it has
to be a reinvention of the mentioned 20% of libtool's wheel, but IMHO
will provide a better DSO solution for applications which _heavily_
count on DSO modules. For instance the command line tool ("dsotool")
is intentionally written in C instead of Bourne Shell to reduce the
processing cost on every compile command and also to reduce portability
problems (which are even more nasty in bootstrap tools like a DSO tool).
It also hasn't to implement all the library-related overhead libtool has
to cover and this way is a smaller package.

So what do I suggest? I suggest you should perhaps wait a little bit
longer before moving on with using libtool/libltdl for dealing with
Apache modules and instead first evaluate my package in a few weeks when
it is publically released. Then you can still use libtool/libltdl for
Apache 2.0 if you will find my DSO package too boring or if it doesn't
fit very well into Apache 2.0. But if you move to libtool too early and
investigate too much time you perhaps will be frustrated later...

Yours,
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com