You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2001/10/04 17:37:55 UTC

Configure for 1.3.21 is semi-"broken"

Just saw this in Configure after Cliff's note (which is resolved):

####################################################################
## Add in the Expat library if needed/wanted.
##

# set the default, based on whether expat-lite is bundled. if it is present,
# then we can always include expat.
if [ "x$RULE_EXPAT" = "xdefault" ]; then
    if [ -d ./lib/expat-lite/ ]; then
        RULE_EXPAT=yes
    else
        RULE_EXPAT=no
    fi
fi

if [ "x$RULE_EXPAT" = "xyes" ]; then
    if ./helpers/TestCompile lib expat; then
        echo " + using system Expat"
        LIBS="$LIBS -lexpat"
    else
        if [ "$xRULE_EXPAT" = "xyes" ]; then
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            echo "ERROR: RULE_EXPAT set to \"yes\" but is not available."
	    exit 1
        fi
        echo " + using builtin Expat"
        EXPATLIB="lib/expat-lite/libexpat.a"
        APLIBDIRS="expat-lite $APLIBDIRS"
        CFLAGS="$CFLAGS -DUSE_EXPAT -I\$(SRCDIR)/lib/expat-lite"
    fi
fi

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
of this, it's pretty important that we test out 1.3.21 as well as
possible, especially with those platforms that provide expat. I
don't think there's a need to hold off on 1.3.21 at present though.

Sorry I didn't notice this sooner... After the dust settles I'll
adjust this section to deal with the new logic.
-- 
===========================================================================
   Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
      "A society that will trade a little liberty for a little order
                   will lose both and deserve neither"

Re: Configure for 1.3.21 is semi-"broken"

Posted by Greg Stein <gs...@lyra.org>.
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/

Re: Configure for 1.3.21 is semi-"broken"

Posted by Greg Stein <gs...@lyra.org>.
SUMMARY: no worries for 1.3.21; the effect is a less-than-optimal fatal
error message. Will patch in a moment.

-----

Whoops... yes, there *is* a logic error there. The logic should be checking
for the presence of ./lib/expat-lite

Oh... crap. And yes... now I see what you mean about the typo managing to
make this work. grr grumble.

All righty. My original note stands about the purpose of the check (re: the
point about wanting to disable the use of the system expat). But the check
there is wrong.

This will *not* affect the 1.3.21 release. The check is simply to provide a
nice error message when lib/expat-lite is *removed* from the source
distribution. We don't do that, and specifically decided against offering
that as a choice in *our* distributions (third parties could always choose
to do so). Should lib/expat-lite be missing, then in the *default* case,
RULE_EXPAT will be set to no, and we'd be set. The real problem comes up
with a redistributor or third-party module setting RULE_EXPAT to yes and no
system expat, and no expat-lite. In this case, the "nice" error message will
fail to trigger, and we'll end up with a failure trying to config/build the
(missing) expat-lite directory.

Thanks for locating this Jim!

Cheers,
-g

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):
> 
> ####################################################################
> ## Add in the Expat library if needed/wanted.
> ##
> 
> # set the default, based on whether expat-lite is bundled. if it is present,
> # then we can always include expat.
> if [ "x$RULE_EXPAT" = "xdefault" ]; then
>     if [ -d ./lib/expat-lite/ ]; then
>         RULE_EXPAT=yes
>     else
>         RULE_EXPAT=no
>     fi
> fi
> 
> if [ "x$RULE_EXPAT" = "xyes" ]; then
>     if ./helpers/TestCompile lib expat; then
>         echo " + using system Expat"
>         LIBS="$LIBS -lexpat"
>     else
>         if [ "$xRULE_EXPAT" = "xyes" ]; then
> 	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>             echo "ERROR: RULE_EXPAT set to \"yes\" but is not available."
> 	    exit 1
>         fi
>         echo " + using builtin Expat"
>         EXPATLIB="lib/expat-lite/libexpat.a"
>         APLIBDIRS="expat-lite $APLIBDIRS"
>         CFLAGS="$CFLAGS -DUSE_EXPAT -I\$(SRCDIR)/lib/expat-lite"
>     fi
> fi
> 
> 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
> of this, it's pretty important that we test out 1.3.21 as well as
> possible, especially with those platforms that provide expat. I
> don't think there's a need to hold off on 1.3.21 at present though.
> 
> Sorry I didn't notice this sooner... After the dust settles I'll
> adjust this section to deal with the new logic.
> -- 
> ===========================================================================
>    Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
>       "A society that will trade a little liberty for a little order
>                    will lose both and deserve neither"

-- 
Greg Stein, http://www.lyra.org/