You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Bloom <rb...@raleigh.ibm.com> on 1999/12/05 20:49:35 UTC
Apache autoconf leakage :-)
Well, APR has been plugged, but we have an Apache leak now. We are
grabbing things too quickly from php, and not protecting namespaces. I am
trying to get php-4 beta compiling against Apache-2.0, just for fun, but
I'm not getting anywhere, because we grabbed a lot of Apache's autoconf
work directly out of PHP, so we are defining the same macros. The two
obvious ones I have hit are PACKAGE and VERSION. I will be fixing these
very shortly by re-naming them to AP_PACKAGE and AP_VERSION in Apache, but
we need to keep an eye on this. :-)
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: Apache autoconf leakage :-)
Posted by Manoj Kasichainula <ma...@raleigh.ibm.com>.
On Mon, Dec 06, 1999 at 05:08:08PM -0600, Me at IO wrote:
> Actually, I still think the cleanest solution will be to prevent the
> Apache headers that get touched by modules from using autoconf macros,
Just a status update: I think I've almost finished this. I have to fix
httpd.h by moving a big pile of defines to either MPM-specific or
OS-specific header files; then we can include "mpm_defaults.h" or
"os.h" to get these. Then I have one left in http_log.h: a few
small elements in a structure are left out if HAVE_RELIABLE_PIPED_LOGS
isn't defined.
Other than that, this seems to be pretty easy (though it's all
completely untested so far), mostly because there's already a
CORE_PRIVATE define that a bunch of the platform-dependant stuff can
require.
Eventually, it would be cool to separate out everything that should be
accessible outside a module and put it in separate header files. Then,
only these header files would be accessible to modules. Voila! A
defined API!
--
Manoj Kasichainula - manojk@raleigh.ibm.com
IBM, Apache Development
Re: Apache autoconf leakage :-)
Posted by Manoj Kasichainula <ma...@io.com>.
On Mon, Dec 06, 1999 at 09:05:28AM -0500, Ryan Bloom wrote:
> That's why I want to fix this problem. I believe the only fix, is to
> create two config header files. This causes MUCH more work for the
> autoconf/automake maintainers, but much less for others. The first config
> header is internal only, and has all of the regular autoconf/automake
> macros. The second is a MUCH smaller version, which has namespace
> protected versions of these macros.
Actually, I still think the cleanest solution will be to prevent the
Apache headers that get touched by modules from using autoconf macros,
for the same reason that I thought so for APR. Those header files
consist basically of interfaces for our modules, and these interfaces
shouldn't change just because autoconf reported something different.
The only exception to this is the case of calls that are macros on
some platforms and functons on the others. This is just a performance
tweak and probably one that isn't noticable anyway, so I'd just
eliminate it, or allow those one or two config macros to leak
(namespace-protected of course).
>From a brief perusal, doing this doesn't look nearly as hard as I
originally thought. There is only one HAVE_ macro used in httpd.h,
which can be eliminated pretty easily. There's a NEED_ macro which
should, and probably already is, stuffed into ap_config.h instead.
Then, there are some OS-specific functions (the ones I saw were
#ifdefed _OSD_POSIX). If we absolutely have to export these functions
only on some systems (and I don't see why we do), then I guess we
should leak an AP_OS macro as well.
I'd rather someone else did this :), but once the automake work
settles down a bit, I can do it.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"This is not a novel to be tossed aside lightly. It should be thrown with
great force." -- Dorothy Parker
Re: Apache autoconf leakage :-)
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> Doesn't m4 allow you to redefine AC_DEFINE? Alternatively,
Yep, but that doesn't fix the underlying problem. automake requires
certain macros. PACKAGE and VERSION being two of them.
> you might want to pipe config.h through
>
> sed \
> -e s/HAVE_/${prefix}HAVE_/ \
> -e s/PACKAGE/${prefix}PACKAGE/ \
> -e s/VERSION/${prefix}VERSION/
>
> This would cover the majority of macros defined in the config
> header file.
This would work, assuming automake allows it. If I get a chance, I'll
look into it.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: Apache autoconf leakage :-)
Posted by Sascha Schumann <sa...@schumann.cx>.
On Mon, Dec 06, 1999 at 09:05:28AM -0500, Ryan Bloom wrote:
>
> Yeah, I noticed that, but I keep thinking there has to be a better way to
> deal with this. What I really want, is an (AM|AC)_DEFINE_PREFIX which
> would tell automake/autoconf to ALWAYS put some prefix on all of their
> macros.
Doesn't m4 allow you to redefine AC_DEFINE? Alternatively,
you might want to pipe config.h through
sed \
-e s/HAVE_/${prefix}HAVE_/ \
-e s/PACKAGE/${prefix}PACKAGE/ \
-e s/VERSION/${prefix}VERSION/
This would cover the majority of macros defined in the config
header file.
--
Regards,
Sascha Schumann
Consultant
Re: Apache autoconf leakage :-)
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> > This is bad for the same reason that have APR gushing macros is bad,
> > except in reverse. Most third-party modules are going to include our
> > config.h file, if they are using autoconf, we will end up breaking them
> > badly. I am beginning to dislike autoconf intensely.
>
> Even the current stable version of Apache has this problem.
> HAVE_SNPRINTF is the worst macro "leak," and breaks the PHP
> build regularly on Mac OS X.
That's why I want to fix this problem. I believe the only fix, is to
create two config header files. This causes MUCH more work for the
autoconf/automake maintainers, but much less for others. The first config
header is internal only, and has all of the regular autoconf/automake
macros. The second is a MUCH smaller version, which has namespace
protected versions of these macros. This is the approach APR has taken
recently, and it is a big improvement, and it allowed me to clean up the
autoconf stuff in APR.
The other solution I have, and I'm not saying this is right, is to drop
automake/autoconf all together and roll our own similar package. I would
love to look into adding the DEFINE_PREFIX macro I discuss later, but
stupid IP agreements ban me from looking too closely at GPL'ed code. :-)
>
> > I figured that out, which is why I haven't patched it yet. I am going to
> > do some research today to figure out how to get around this problem. But,
> > PHP and any other package that uses automake/libtool really can't work
> > with us if these have to be exposed.
>
> We had this problem as well when we needed to integrate the
> helper libraries (libzend/TSRM) into PHP. All three packages
> use automake, and thus all three config files contain PACKAGE
> and VERSION. To get rid of these conflicting macros, they are
> undefined after the config file is included.
Yeah, I noticed that, but I keep thinking there has to be a better way to
deal with this. What I really want, is an (AM|AC)_DEFINE_PREFIX which
would tell automake/autoconf to ALWAYS put some prefix on all of their
macros.
I will be undef'ing these in Apache today, but I would urge that we find a
better solution or drop automake/autoconf all together.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: Apache autoconf leakage :-)
Posted by Sascha Schumann <sa...@schumann.cx>.
On Mon, Dec 06, 1999 at 07:09:33AM -0500, Ryan Bloom wrote:
>
> > Apache is gushing macros, because everything has to include
> > ap_config_auto.h.
> >
> > The only way I can think of to avoid this is to not include
> > ap_config.h in httpd.h. I'm guessing this won't be a simple task,
> > though.
>
> This is bad for the same reason that have APR gushing macros is bad,
> except in reverse. Most third-party modules are going to include our
> config.h file, if they are using autoconf, we will end up breaking them
> badly. I am beginning to dislike autoconf intensely.
Even the current stable version of Apache has this problem.
HAVE_SNPRINTF is the worst macro "leak," and breaks the PHP
build regularly on Mac OS X.
>
> >
> > > The two obvious ones I have hit are PACKAGE and VERSION. I will be
> > > fixing these very shortly by re-naming them to AP_PACKAGE and
> > > AP_VERSION in Apache
> >
> > PACKAGE and VERSION are set by AC_INIT_AUTOMAKE, and the automake docs
> > say these are required. Plus there are the various HAVE_blah macros
> > made by automake which would just be pure hell to try to cram into a
> > namespace.
>
> I figured that out, which is why I haven't patched it yet. I am going to
> do some research today to figure out how to get around this problem. But,
> PHP and any other package that uses automake/libtool really can't work
> with us if these have to be exposed.
We had this problem as well when we needed to integrate the
helper libraries (libzend/TSRM) into PHP. All three packages
use automake, and thus all three config files contain PACKAGE
and VERSION. To get rid of these conflicting macros, they are
undefined after the config file is included.
--
Regards,
Sascha Schumann
Consultant
Re: Apache autoconf leakage :-)
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> Apache is gushing macros, because everything has to include
> ap_config_auto.h.
>
> The only way I can think of to avoid this is to not include
> ap_config.h in httpd.h. I'm guessing this won't be a simple task,
> though.
This is bad for the same reason that have APR gushing macros is bad,
except in reverse. Most third-party modules are going to include our
config.h file, if they are using autoconf, we will end up breaking them
badly. I am beginning to dislike autoconf intensely.
>
> > The two obvious ones I have hit are PACKAGE and VERSION. I will be
> > fixing these very shortly by re-naming them to AP_PACKAGE and
> > AP_VERSION in Apache
>
> PACKAGE and VERSION are set by AC_INIT_AUTOMAKE, and the automake docs
> say these are required. Plus there are the various HAVE_blah macros
> made by automake which would just be pure hell to try to cram into a
> namespace.
I figured that out, which is why I haven't patched it yet. I am going to
do some research today to figure out how to get around this problem. But,
PHP and any other package that uses automake/libtool really can't work
with us if these have to be exposed.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: Apache autoconf leakage :-)
Posted by Manoj Kasichainula <ma...@io.com>.
On Sun, Dec 05, 1999 at 02:49:35PM -0500, Ryan Bloom wrote:
>
> Well, APR has been plugged, but we have an Apache leak now.
Apache is gushing macros, because everything has to include
ap_config_auto.h.
The only way I can think of to avoid this is to not include
ap_config.h in httpd.h. I'm guessing this won't be a simple task,
though.
> The two obvious ones I have hit are PACKAGE and VERSION. I will be
> fixing these very shortly by re-naming them to AP_PACKAGE and
> AP_VERSION in Apache
PACKAGE and VERSION are set by AC_INIT_AUTOMAKE, and the automake docs
say these are required. Plus there are the various HAVE_blah macros
made by automake which would just be pure hell to try to cram into a
namespace.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/