Paul Iadonisi <[EMAIL PROTECTED]> writes:
> I forgot to mention that I did do a Google search on 'sablotron expat apache > segfault' and found lots of references to this exact type of problem. The > results seem to universally point to multiple copies of the expat processor due > to the fact that many products (apache included) include their own copy > of expat. You need to verify that you have *one* *consistant* version of expat on your system. > Depending on the version, whether it's linked statically or > dynamically and anything else you are using that needs expat, there can be > serious conflicts. It has something to do with instantiating the parser > multiple times and then the code that makes the call to the parser doesn't > know which instance to call. Something like that. Har! I wonder if they use yacc for their parser... > Anyhow, based on what I read, it appears that I've got everything set right. > Red Hat's apache 1.3.22 update links dynamically to the external expat. So > does the 0.71 rpm of sablotron from the Ginger Alliance. Even the > perl-XML-Parser is linked dynamically, though we don't use that. The only > thing I can think of that might not be is php (which we use a small bit of), > but we don't even use any of the XML stuff in php and I don't think we've > even reached the point where php would be loaded. I may be wrong, though, > as I know little about the inner workings of apache. Do you happen to end up with a file named "core" anywhere as a result of this problem? Are there any references to LD_LIBRARY_PATH anywhere in this mix? --kevin -- Kevin D. Clark (CetaceanNetworks.com!kclark) | Cetacean Networks, Inc. | Give me a decent UNIX Portsmouth, N.H. (USA) | and I can move the world alumni.unh.edu!kdc (PGP Key Available) | ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
