httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: cvs commit: httpd-2.0
Date Fri, 09 Mar 2001 15:07:08 GMT
From: "Greg Stein" <>
Sent: Friday, March 09, 2001 9:01 AM

> On Fri, Mar 09, 2001 at 07:59:30AM -0600, William A. Rowe, Jr. wrote:
> > From: "Greg Stein" <>
> > Sent: Friday, March 09, 2001 7:46 AM
> >...
> > > Now that you've done a ton of work in xml/expat, I'm going to propagate a
> > > bunch of that work back to the main Expat repository (along with Ryan's
> > > compiler warning patches). The ideal is for xml/expat to look just like the
> > > standard Expat CVS. However, we may always end up with a different Windows
> > > build (for example: you're only building static, but the official CVS needs
> > > to build DLLs). I know that I can get the Unix side in sync between
> > > httpd-2.0 and Expat's CVS.
> > 
> > I'm looking forward to it.  I'll be happy to patch expat.dsp this weekend,
> > which I didn't use since we didn't need a .dll for win32.
> Actually, we could use the .dll form on Windows. It is sharable, which
> should avoid some of the problems we saw with expat-lite being built in and
> exporting its symbols. The hope for Unix is to always build our expat as a
> .so, thus allowing other modules (e.g. Perl's expat wrapper) to also bind
> against it.
> [ if .so's aren't available, then the person is creating a monolithic Apache
>   anyways, so symbol conflicts shouldn't occur; there may be some wonky
>   variations in here, but that's my initial thought ]

The problem is backwards on Win32.  Monoliths see the .lib file objects, and may
have conflicts.  The libdavutil.dll doesn't export a single expat symbol, so the 
dynamic build of apr-util is very safe from conflicts.

> > The biggest issue was the versioning and conf file rewriting.  Do we need to
> > do this at our level, or can that come with the version rather than three
> > substs for the version indirected?
> > 
> > I ask since it would be much cleaner to just create the versioning in the
> > release and checkout, rather than end users rewriting it.
> At the Python Conference, I spoke with the current admin of the Expat
> project (Fred Drake). Basically, he said "do what you think is best, but
> just don't break it [and I trust you / know you wouldn't]."
> So we can do whatever we think is best. Also, I told him "we [the ASF /
> httpd group] have great Win32 talent, so we can fix up Expat's win32
> issues." He was quite pleased :-) [ basically, he couldn't keep the .dsp
> maintained properly and/or set it up "well" ]
> The numbers originate in, and propagate into libtool and into
> lib/expat.h. In the CVS copy, they would stash a generated copy of expat.h,
> which allowed the Windows platform access to those values. In our bundled
> Expat, we don't keep generated values, so they disappeared :-(
> The right answer might be to put the "real" values into expat.h and stop
> generating that file. can extract the values from expat.h and
> feed them to libtool. Windows would just use expat.h.
> The (CVS-Expat) release process would tweak the values in expat.h, rather
> than values in
> Seem like a plan?

That's about as easy as it gets.  My #ifdef protection is probably right, though,
in case you want to build a test version only tweaking XML_MICRO_VERSION.


View raw message