httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Travis <>
Subject Re: libltdl?
Date Tue, 28 Mar 2000 17:54:17 GMT
I'll take a stab at this, Ryan,

We are not talking about creating shared libraries -- only using them.  David is
correct.  However, in response to his note:
"If we're going down the full Libtool path then whyd we need a dso directory?"
The answer is very simple:  Someone has done the work for us to having working
shared library support on many many platforms, with a common interface.  This
takes care of a ton of our supported operating systems.  Now then, Why don't we
use ltdl everywhere?  What happens on windows?  Isn't this what APR is all about?
Just create a new directory under the dso directory, for handling these other
operating systems.  This is exactly what my patches put into place for Os/2, etc.

WRT 'why we need libtool', I think this is a temporary issue while Ralf finishes
his code for dsotool.  Keep in mind though that his dsotool will just be another
'library' or utility that APR will have to rely on (the same as libtool).  The way
you are talking about solving this problem, it sounds like you want to re-write
libtool within APR.  Be my guest.. ;-)

If we remove libtool stuff form APR (i.e. don't like with libltdl), then Apache
will be cluttered with different implementations of how to load shared libraries,
which is what APR is all about.

-- Jon wrote:

> Okay, I'm getting much more conviced here.  In fact, I am seriously
> leaning towards removing the libtool stuff from APR.  I would love to hear
> some arguments from the other side before I give it my +1 though.  :-)
> Ryan
> > We're not talking about creating shared libraries, just using them.  If
> > we're going down the full Libtool path then why d we need a dso
> > directory?  We could just use the ltdl everywhere.  What happens on
> > Windows?  We'd have to figure that out and then we're back to writing
> > wrappers for the ltdl stuff, which seems a bit strange.  I don't mind
> > either way but if we do it then do we also use libtool for building
> > APR?  APR builds nice and simply now, has very little reliance on other
> > platforms and as we don't need to create libraries/modules, then why
> > demand libtool?
> >
> > If there are bugs then we can find and fix them.  Looking at the code
> > in os.c it strikes me that AIX should have a seperate directory for DSO
> > to keep the code more readable.  It's easy enough to do after all!
> >
> > d.
> >
> > >
> > >I would prefer to keep libtool out of APR, personally.  There are bugs
> > >with the Apache 1.3 code, and those would need to be fixed.  I also
> > know
> > >that this basically means we are duplicating somebody else's work, and
> > I
> > >dislike that idea.  Libtool has solved this problem, and we really
> > >shouldn't solve it again.  Perhaps the best solution is to use libtool
> > >until dsotool comes out, and then use it, like we have suggested
> > before.
> > >
> > >I hope you can tell I am torn on this issue.  I would like to keep APR
> > >small and flexible and as unreliant on other libraries as possible,
> > but I
> > >would also rather not duplicate work.  I am perfectly willing to be
> > >persuaded one way or the other.
> > >
> > >Ryan
> > >
> > >On Tue, 28 Mar 2000, David Reid wrote:
> > >
> > >> Up until now we haven't required libtool to build APR.  The recent
> > dso
> > >> stuff changes all that!  Now, I don't mind if we have to add libtool
> > >> usage to APR, but I'd rather not.  APR is supposed to be "stand-
> > alone"
> > >> as a library.  I know the edges have been "blurring" slightly but up
> > >> until this change you could build APR by simply doing
> > >> autoconf;configure;make and all was OK.  You still can for OS2 or
> > BeOS,
> > >> but as the Unix dso code needs ltdl you can't.
> > >>
> > >> So do we just go back to using the code from 1.3.x with all it's
> > >> variants for Unix?  It'd be more in keeping with APR to date and
> > >> shouldn't really change anything.
> > >>
> > >> d.

View raw message