On Thu, Oct 04, 2001 at 11:37:55AM -0400, Jim Jagielski wrote: > Just saw this in Configure after Cliff's note (which is resolved): >... > Note the line above the '^^^^'. Luckily, this section still works > as required (lucky typo)... But there's a mismatch of logic here, regarding > what the EXPAT rule really means... Right now, if there's a system > expat lib, it will *always* be chosen, and there's no way to bypass > that. Up to now, I think we've always been using expat-lite... Because
The *intent* is to always choose the system Expat over our bundled version. This also happens to be the same behavior that we now have in apr-util. RULE_EXPAT in Apache 1.3 means "give me Expat". Doesn't matter *where* it comes from, as long as it is available in the process. Point being that we want to use the system's .so when possible, so that other things in the Apache process which need Expat will link against the *same* .so. In the current world, if Apache brings Expat symbols into the process, and something down the line also brings in Expat (because it doesn't know Expat has already been loaded), then we get all kinds of problems. The specific scenario is that mod_perl runs a Perl script which loads the standard XML::Parsers::Expat module; that module knows *nothing* about Apache. All it can know about is the system Expat. Apache has no need to provide its own, so choosing the system version is always preferable. Since the Expat API is way stable, this works quite fine. >... > Sorry I didn't notice this sooner... After the dust settles I'll > adjust this section to deal with the new logic. Um... *why* would you want to disable the use of the system version in favor of the builtin one? I don't see and can't imagine a use case for that. (which is why I coded the selection this way) Cheers, -g -- Greg Stein, http://www.lyra.org/
