Re: libexpat

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 08:05 PM 5/21/2002, you wrote:
>On Tue, 21 May 2002, Greg Stein wrote:
>
> > Euh... we switched over to a shared library to specifically fix this
> > problem. Are you saying that that didn't work? I'm not buying it... :-)
>
>sooo, i guess the answer to my question on how to disable expat is
>"you can't" ?
>
>i haven't see the problem first hand, it was reported by a user who's
>running winnt, the server crashes using the XML::LibXML extension within
>modperl.  might not be related to expat at all, but if there were a way to
>disable it, i would ask the user to try that first.

I suspect they are linking to the wrong expat.lib or including the wrong
expat.h headers, not bumping into expat through libaprutil.dll.

A quick grok of libaprutil.dll through the eyes of depends.exe [bundled
with the SDK and all MS compiler tools] shows that no xml symbols
leaked from our copy into anywhere but expat.lib [static.]

OTOH, I find three non-decorated bits of fooness in aprutil...

match_boyer_moore_horspool
match_boyer_moore_horspool_nocase
match_no_op

That's not good.

libapr.dll looks clean, while libhttpd.dll leaks

core_module
_find_child_by_pid@4
http_module
_mpm_get_completion_context@0
_mpm_post_completion_context@8
_mpm_recycle_completion_context@4
mpm_winnt_module
so_module
win32_module

of which I will accept the _module exports, but I can't stomach the mpm_*
or  find_child_by_pid fooness, none of which should need to be exported!