httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: [PATCH] Expat patch #3
Date Fri, 21 May 1999 20:37:00 GMT

In article <3745C109.78FF503@lyra.org> you wrote:
> 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)

Wait, let me understand it again. What you propose is to just export the
symbols. Ok, but then doesn't mean that the Expat stuff is really all linked
into the httpd, isn't it? When all(!) code is linked in, this exporting will
work, of course. But when not all code gets linked in the exporting is useless
AFAIK. We do the ap_xx() wrapper stuff not just because of exporting.  We've
to still export the ap_xx(), of course. We do it to force the linker to
include the whole(!) Expat into httpd so the whole Expat library is available
to DSOs when we try to export the stuff.

When we just try to export the symbols and hope that this way on most
platforms Expat is forced to be linked into httpd, this is just a guess about
linker behaviour and not really portable and clean IMHO. That's why I'm still
not convinced that this "just try to export the symbols" is reasonable.

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message