Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Sat, 1 Apr 2000 12:10:31 -0500 (EST)
From: rbb@apache.org
To: new-httpd@apache.org
Subject: Re: libtool in APR.
In-Reply-To: <38E4D714.E15E4CA7@covalent.net>
Message-ID: <Pine.LNX.4.10.10004011203560.19568-100000@shell.ntrnet.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: rbb@shell.ntrnet.net


> I understand your opinion about wanting to get another 2.0 alpha
> out the door.  The main reason for my DSO patches was that I
> was trying to develop a module, and with the current state of
> Apache, it was not possible to work on it without butchering
> the Apache source tree.  (Does 2.0 yet support inclusion
> of static modules as libraries?)  This DSO patch solves that
> problem perfectly for me, and I was thinking that if anyone else
> wanted to do a lot of module work that this would be quite handy
> to them.

This is untrue.  There are two types of Apache modules, and they have
always been handled differently.  Single file modules and multi-file
modules.  

For a single file module, use --with-module=location.  This does work.

For multi-file modules, nobody has added support for those yet.
Regardless, the problem shouldn't be loading already compiled modules.
Rather the problem is with the configure script and getting it to find the
correct files and compile them.  Harrie Hazewinkel wrote a patch against
"./configure" which supports multi-file modules, but it doesn't apply
cleanly because it is against a generated file.  I have been working on
getting multi-file modules to be configured, but I haven't been focusing
on it.

> o)  dsotool may not be the be-all-end-all for the DSO loading,
> it currently exists in a lot of minds as the fix to all the
> problems.  Nobody really knows.  (this is my own paraphrase.;-))
> 
> If a much nicer (cleaner) libtool patch would be accepted into
> the tree, I'd whip one up, no problemo.  It works, it allows
> people to work on DSOs in this 'limbo' stage, and it provides
> as an API with which we can change the backend later if we
> feel that Ralf can end world-hunger.. ;-)  Libltdl has always
> built very nice for me on all the platforms I've ever developed
> for -- it doesn't seem like much of a burden at all.

But we already have at least one report of a platform that it doesn't work
on.  We also already have code that does work (it's been working in 1.3.X
for a long time).  I think the biggest complaint about using libtool is
that APR then relies on libtool.  I do not know how other people feel
about that, but I really dislike it.  We have a reliance on one other
library currently, MM.  MM is a part of our tree, and therefore does not
require APR users to go get another library to get things to work.

This is the stumbling block as I see it.  If somebody else sees another
stumbling block, please let me know.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------