Re: libexpat
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
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
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
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 [EMAIL PROTECTED] San Diego, CA, US http://Sander.vanZoest.com/
Re: libexpat
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
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
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
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
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?
Re: libexpat
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
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
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