You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Doug MacEachern <do...@covalent.net> on 2002/05/21 03:00:12 UTC
libexpat
how does one disable linking httpd against libexpat in 2.0?
and on win32?
i thought the nightmare was over where the expat linked with httpd cause
segfaults with perl expat extensions. looks like i was wrong.
Re: libexpat
Posted by Sander van Zoest <sa...@vanzoest.com>.
On Mon, 20 May 2002, Jon Travis wrote:
> On Mon, May 20, 2002 at 09:54:16PM -0500, William A. Rowe, Jr. wrote:
> > At 09:43 PM 5/20/2002, you wrote:
> > >On Mon, 20 May 2002, William A. Rowe, Jr. wrote:
> > > > Context?
> > >httpd links in expat, perl extension links against a different version of
> > >expat. both have the same symbol names, and they are not binary
> > >compatible. perl extension resolves symbols to the httpd version.
> > >kaboom. its been an issue for years with 1.3, you'll find plenty in the
> > >modperl archives on it.
> > Can we somehow draw one from the two?
> > Of course that's win32 (or OS X) ... on Unix I can imagine this is hellish,
> > no matter how we try solving it.
> This same stuff comes up every few months. Python modules had the same
> issue with PCRE stuff (surprised mod_perl doesn't have that issue).
Same issue with libc's regcomp and hsregex. We probably will have the same
issue with APR as well.
--
Sander van Zoest sander@vanzoest.com
San Diego, CA, US http://Sander.vanZoest.com/
Re: libexpat
Posted by Jon Travis <jt...@covalent.net>.
On Mon, May 20, 2002 at 09:54:16PM -0500, William A. Rowe, Jr. wrote:
> At 09:43 PM 5/20/2002, you wrote:
> >On Mon, 20 May 2002, William A. Rowe, Jr. wrote:
> >
> > > Context?
> >
> >httpd links in expat, perl extension links against a different version of
> >expat. both have the same symbol names, and they are not binary
> >compatible. perl extension resolves symbols to the httpd version.
> >kaboom. its been an issue for years with 1.3, you'll find plenty in the
> >modperl archives on it.
>
> Can we somehow draw one from the two?
>
> In all fairness, I'm surprized this is much of an issue on Win32... we
> don't have a flat namespace. If you dig into libhttpd and libaprutil, you
> should discover no expat symbols exported (the depends utility should
> let you see any exports/used symbols.)
>
> Of course that's win32 (or OS X) ... on Unix I can imagine this is hellish,
> no matter how we try solving it.
>
This same stuff comes up every few months. Python modules had the same
issue with PCRE stuff (surprised mod_perl doesn't have that issue).
-- Jon
Re: libexpat
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 09:43 PM 5/20/2002, you wrote:
>On Mon, 20 May 2002, William A. Rowe, Jr. wrote:
>
> > Context?
>
>httpd links in expat, perl extension links against a different version of
>expat. both have the same symbol names, and they are not binary
>compatible. perl extension resolves symbols to the httpd version.
>kaboom. its been an issue for years with 1.3, you'll find plenty in the
>modperl archives on it.
Can we somehow draw one from the two?
In all fairness, I'm surprized this is much of an issue on Win32... we
don't have a flat namespace. If you dig into libhttpd and libaprutil, you
should discover no expat symbols exported (the depends utility should
let you see any exports/used symbols.)
Of course that's win32 (or OS X) ... on Unix I can imagine this is hellish,
no matter how we try solving it.
Re: libexpat
Posted by "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!
Re: libexpat
Posted by "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!
Re: libexpat
Posted by Doug MacEachern <do...@covalent.net>.
On Wed, 22 May 2002, Greg Ames wrote:
> Which release of httpd? 1.3 has a Configure rule to turn off expat.
right. i'm asking about 2.0 (my original message specified)
Re: libexpat
Posted by Greg Ames <gr...@apache.org>.
Doug MacEachern 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" ?
Which release of httpd? 1.3 has a Configure rule to turn off expat.
Greg
Re: libexpat
Posted by Doug MacEachern <do...@covalent.net>.
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.
Re: libexpat
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:45 PM 5/21/2002, you wrote:
>On Mon, May 20, 2002 at 07:43:49PM -0700, Doug MacEachern wrote:
> > On Mon, 20 May 2002, William A. Rowe, Jr. wrote:
> >
> > > Context?
> >
> > httpd links in expat, perl extension links against a different version of
> > expat. both have the same symbol names, and they are not binary
> > compatible. perl extension resolves symbols to the httpd version.
> > kaboom. its been an issue for years with 1.3, you'll find plenty in the
> > modperl archives on it.
>
>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... :-)
If both use the same named expat.dll, on win32 we -will- explode. If the
symbols are static and not exported as part of one or the other project,
there should not be a conflict. Because win32 won't expose un-exported
symbols (and the user should only expect our apr-util XML interface calls)
this shouldn't pose a problem, but I'll research further.
Linking our static build of expat.lib plus perl? Well now you have a real
kaboom, probably.
Bill
Re: libexpat
Posted by Greg Stein <gs...@lyra.org>.
On Mon, May 20, 2002 at 07:43:49PM -0700, Doug MacEachern wrote:
> On Mon, 20 May 2002, William A. Rowe, Jr. wrote:
>
> > Context?
>
> httpd links in expat, perl extension links against a different version of
> expat. both have the same symbol names, and they are not binary
> compatible. perl extension resolves symbols to the httpd version.
> kaboom. its been an issue for years with 1.3, you'll find plenty in the
> modperl archives on it.
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... :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: libexpat
Posted by Greg Ames <gr...@apache.org>.
Doug MacEachern wrote:
> httpd links in expat, perl extension links against a different version of
> expat. both have the same symbol names, and they are not binary
> compatible. perl extension resolves symbols to the httpd version.
> kaboom. its been an issue for years with 1.3, you'll find plenty in the
> modperl archives on it.
Speaking of 1.3 expat, I built a 1.3.24 Linux binary on my Mandrake 8.0 laptop
the other day with binbuild.sh. I was surpised when one of the IBM testers told
me he couldn't bring it up on his SuSE box, because it couldn't find
libexpat.so.0 or some such.
It turns out that my ThinkPad has native expat support installed; the SuSE box
doesn't. The Configure script prefers the system's expat to our bundled
version. Makes sense, except for binbuilds where supporting the lowest common
denominator is a winner. I hacked Configure to bundle our expat and the SuSE
tester was happy.
When I mentioned this to other Apachers around here, I got differing opinions on
what the Right Thing is for a binbuild. One thought was to disable expat
altogether in 1.3 binbuilds since they don't include mod_dav. Another thought
was to always bundle expat so that external modules can use it.
I wouldn't mind spending a little time to resolve this if we had a consensus on
what it should do. Doug and Will's comments make disabling expat in 1.3
binbuilds sound better.
Greg
Re: libexpat
Posted by Doug MacEachern <do...@covalent.net>.
On Mon, 20 May 2002, William A. Rowe, Jr. wrote:
> Context?
httpd links in expat, perl extension links against a different version of
expat. both have the same symbol names, and they are not binary
compatible. perl extension resolves symbols to the httpd version.
kaboom. its been an issue for years with 1.3, you'll find plenty in the
modperl archives on it.
Re: libexpat
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 08:00 PM 5/20/2002, you wrote:
>how does one disable linking httpd against libexpat in 2.0?
>and on win32?
>
>i thought the nightmare was over where the expat linked with httpd cause
>segfaults with perl expat extensions. looks like i was wrong.
Context?