httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [PATCH] Expat patch #3
Date Fri, 21 May 1999 20:24:41 GMT
Ralf S. Engelschall wrote:
> 
> In article <Pine.LNX.3.96dg4.990521095534.13415K-100000@twinlark.arctic.org> you
wrote:
> >
> > On Fri, 21 May 1999, Jens-Uwe Mager wrote:
> >
> >> On Fri, May 21, 1999 at 09:40:34AM -0700, Dean Gaudet wrote:
> >>
> >> > Can't we just put the expat symbols into the export file on those systems?
> >>
> >> Yep, as it is unlikely that you find that symbols in libc you could
> >> simply export them. The trend to rename is mostly with symbols that
> >> could conflict with libc, these systems tend to use symbols from libc
> >> in preference to symbols imported from the main executable (in the
> >> DSO/shlib case).
> >
> > So we could get away with not renaming expat then?  (expat won't be part
> > of libc on these systems... at least I hope it isn't :)
> >
> > I'd be a lot happier not renaming expat.
> 
> "Renaming Expat"? We don't rename or change anything inside Expat, of course.
> What we do is just to use ap_xml_xxx() wrapper functions which make sure all
> Expat code is linked into the Apache core code. That's at least 100% portable
> and doesn't suffer from any linker/export restrictions. And this way we've not
> to link every DSO against the Expat library, of course.

The wrappers are effectively renaming the Expat functions.

You could restate Dean's comment as "I'd be a lot happier not wrapping
expat."

I agree and would prefer just dropping the Expat symbols into the .def
and .exp files. Each Expat symbol has an appropriate prefix (XML_) so no
ocnflict will occur. Based on Jens-Uwe Mager's email, that will work
fine for the platforms we care about.

Ralf: could you remove your veto, or at least alter it to just the
http_main.c portion of the patch? (so the src/lib/ stuff can go in)

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

Mime
View raw message