httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: DSO Patch 1 of 3 (+ commentary!)
Date Sun, 26 Mar 2000 10:11:12 GMT

In article <20000325192827.A2870@manojk.users.mindspring.com> you wrote:
> On Sat, Mar 25, 2000 at 02:40:06PM +0100, Ralf S. Engelschall wrote:
>> I personally differentiate between modules ("active DSOs which are
>> managed explicitly") and libraries ("passive DSOs which are managed
>> implicitly") an hence recently started to write a new package
>> (distributed under a MIT-style license for those who like to always
>> blame me for my packages ;) which doesn't contain all the
>> library-related overhead of libtool.
> 
> +1 if it can be done (and portable, etc.) in time for Apache 2.0. How
> easy will it be to drop in dsotool in place of libtool? 

Very easy. Dsotool uses the same "prefix your compile and link commands
in Makefiles with the tool command" approach from libtool. So it is very
easy to switch, although this effect is more or less just a coincidence
and not a design goal. I just found that this approach provides more
flexibility than Apache 1.3's approach of the extra DSO variables. So I
took over libtool's approach. 

But I certainly do not focus on making a transition from libtool
to dsotool easy, because (as I tried to explain) dsotool is not a
replacement for libtool - its a companion tool. dsotool is for DSO
modules while libtool is for DSO libraries. So they actually have a
disjunct field of application if they are used correctly.

> Also, will
> dsotool support backward compatibility with libtool? 

No, it cannot. Because dsotool's functionality is a _subset_ of
libtool's functionality. For instance all library-related fiddling
(symlinks .so.X.Y, .libdir subdir, etc.) dsotool does not provide,
because it has not to provide it (because its not necessary for DSO
modules).

> These features
> would be really nice, because then we could go ahead with libtool now
> and switch to dsotool later (or even allow a compile-time selection).

This is nevertheless possible, at least as long as you use libtool with
care. That is, you use the subset of libtool's functionality which is
also present in dsotool.

> BTW, has anyone checked out what XFree86 4.0 is doing? They allegedly
> have DSOs which are portable. Not just source, but binaries (at least
> on Intel OSes). I have no clue how/if they pull this off, but wouldn't
> it be cool if we used this code? XFree86 is under a liberal enough
> license IIRC.

The DSO stuff in XFree86 is still not as portable is it looks (from
their release notes):

"The loader in version 4.0 has support for Intel (x86), Alpha and
PowerPC platforms. It also has preliminary support for Sparc platforms
but this isn't used yet."

Nevertheless their stuff looks very interesting, too. But whether it can
be of use also for Apache we have to evaluate in depth. I'll look at
this the next days.
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message