You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ma...@hyperreal.org on 1999/12/20 02:54:40 UTC
cvs commit: apache-2.0/src buildconf configure.in
manoj 99/12/19 17:54:40
Modified: src buildconf configure.in
Log:
Make Apache's configure script run APR's.
Revision Changes Path
1.4 +0 -3 apache-2.0/src/buildconf
Index: buildconf
===================================================================
RCS file: /home/cvs/apache-2.0/src/buildconf,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -u -r1.3 -r1.4
--- buildconf 1999/12/20 01:44:59 1.3
+++ buildconf 1999/12/20 01:54:38 1.4
@@ -128,6 +128,3 @@
rm config.cache
./configure
-cd lib/apr
-rm config.cache
-./configure
1.10 +3 -0 apache-2.0/src/configure.in
Index: configure.in
===================================================================
RCS file: /home/cvs/apache-2.0/src/configure.in,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -u -r1.9 -r1.10
--- configure.in 1999/12/05 10:33:40 1.9
+++ configure.in 1999/12/20 01:54:39 1.10
@@ -21,6 +21,9 @@
dnl Needed for APACHE_MODULE() to work
cwd=`pwd`
+dnl ## Run configure for packages Apache uses
+AC_CONFIG_SUBDIRS(lib/apr)
+
dnl ## Check for programs
AC_PROG_AWK
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by Manoj Kasichainula <ma...@io.com>.
On Sun, Dec 19, 1999 at 08:33:55PM -0600, Me at IO wrote:
> On Mon, Dec 20, 1999 at 02:15:12AM +0000, Ben Laurie wrote:
> > OK, but the config.cache should still be removed, surely?
>
> Hmmm. Yeah, I guess it makes sense.
Actually, that's not necessary. One of the benefits of using
AC_CONFIG_SUBDIRS is that the configure script from APR is told to use
the existing config.cache. This is cool, because it saves a lot of
time rechecking stuff, and we also don't have to worry about multiple
config.caches
> Well, now, all you should have to do in theory is (thanks to your
> work):
Actually, with a couple of changes I just made, the steps are:
cd src
./buildconf
./configure --flags
make
I can document this in the repository, but there are already enough
READMEs and install documents that one more is just going to get
confusing. I'd like to add the docs when we've crossed the point of no
return; after/if we delete the old configuration system.
The most important flags (visible with ./configure --help) are:
--with-mpm=MPM_NAME
--enable-MODULE (and yes, --disable works)
--disable-shared (will speed up compiles; I may make this the default
until DSOs work)
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by Manoj Kasichainula <ma...@io.com>.
On Mon, Dec 20, 1999 at 02:15:12AM +0000, Ben Laurie wrote:
> OK, but the config.cache should still be removed, surely?
Hmmm. Yeah, I guess it makes sense. I'll put that back. It's probably
better to remove all sorts of other stuff, like config.log.
Actuallly, --enable-maintainer-mode ought to take care of a lot of
this for us, in theory. Haven't checked if it actually does, though.
> Also, BTW, the current version completely fails to build for me (lots of
> unresolved externals) - what's the current recommended build path?
Well, now, all you should have to do in theory is (thanks to your
work):
cd src
./buildconf
./configure --flags
cd lib/apr
make
cd ../..
make
It works for me on Linux. Unfortunately, I haven't tested on any other
platforms yet; I'm just trying to get it to work on a single platform
first. RSN, I should have a BSD box up and running.
> I'm slightly puzzled by what's going on with APR - it seems to build a
> dozen different libraries, but Apache only seems to use one. What am I
> missing?
I think a bunch of libraries are built and then combined together,
sort of like Apache combines a bunch of libraries together in its
build process. I haven't checked out APR's build process too
carefully, though.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by Sascha Schumann <sa...@schumann.cx>.
On Tue, Dec 21, 1999 at 01:53:15PM -0600, Manoj Kasichainula wrote:
> On Tue, Dec 21, 1999 at 08:16:54PM +0100, Sascha Schumann wrote:
> > > -pthread also turns on -D_REENTRANT on my Linux box.
> >
> > You are probably using gcc-2.95.2. That is the first gcc
> > release which also enables -D_REENTRANT on Linux when
> > -pthread is used. Needless to say that this specific gcc
> > version isn't widely available.
>
> Actually, I'm using egcs 1.1.2, which is now distributed with Red Hat,
> and I believe other distributions as well. But, if gcc 2.7 doesn't support it,
> then yeah, there's more evidence that we should add it.
gcc-2.95.2 does not define _REENTRANT on Linux/Alpha yet
(that is where I checked it initially). It seems to be
defined for a longer period of time on Linux/x86.
Btw, Solaris' gcc supports -pthreads (note the trailing s).
Portability nightmare, here we go.
--
Regards,
Sascha Schumann
Consultant
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by Manoj Kasichainula <ma...@io.com>.
On Tue, Dec 21, 1999 at 08:16:54PM +0100, Sascha Schumann wrote:
> > -pthread also turns on -D_REENTRANT on my Linux box.
>
> You are probably using gcc-2.95.2. That is the first gcc
> release which also enables -D_REENTRANT on Linux when
> -pthread is used. Needless to say that this specific gcc
> version isn't widely available.
Actually, I'm using egcs 1.1.2, which is now distributed with Red Hat,
and I believe other distributions as well. But, if gcc 2.7 doesn't support it,
then yeah, there's more evidence that we should add it.
> > Are there any good autoconf macros that have all this stuff
> > encapsulated already?
>
> None which perform OS-specific checks.
I've been pointed at the Python configure.in. I don't know whether it
does OS-specific checks (it's doesn't for -D_REENTRANT), but it's a
good place to start.
Manoj
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by Sascha Schumann <sa...@schumann.cx>.
On Tue, Dec 21, 1999 at 12:38:09PM -0600, Manoj Kasichainula wrote:
> On Tue, Dec 21, 1999 at 05:25:05PM +0100, Sascha Schumann wrote:
> > Well, it is not that easy. First, -pthread isn't relevant to
> > the compile stage. It should be put into LDFLAGS (it causes
> > -lc_r or -lpthread on FreeBSD or Linux, respectively).
>
> On Linux systems that I've checked, -pthread implies -lpthread, and it
> seems to be working for me in just the CFLAGS. In fact, it's curious
> that nothing is needed in LDFLAGS; I guess that since gcc is used as
> the linker, autoconf is also appending CFLAGS. *shrug*
It's fairly simply. Look at automake's LINK line
LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@
> > Second, a number of macros are needed. On Linux, it is
> > _REENTRANT (see <features.h>).
>
> -pthread also turns on -D_REENTRANT on my Linux box.
You are probably using gcc-2.95.2. That is the first gcc
release which also enables -D_REENTRANT on Linux when
-pthread is used. Needless to say that this specific gcc
version isn't widely available.
> > On FreeBSD, no special flags are needed (AFAIK; the fact that
> > the thread-safe PHP binary builds flawlessly supports this.
>
> Actually, I don't think not including -D_REENTRANT will make any
> compiles fail if you try compiling threaded code; it will just make
> your code not work :(. If FreeBSD doesn't also add an implied
> -D_REENTRANT, then yeah, we should do so.
The code actually works. As I said before, FreeBSD doesn't
use _REENTRANT extensively. _REENTRANT will cause four
additional prototypes to be defined, and nothing else (this
is -current, -stable should be similar). These are reentrant
versions of math functions..
I've also hunted additional macros, but there don't seem to
be any important ones. You will get a few more prototypes, if
you define _POSIX_C_SOURCE=199309L, but I don't know whether
Apache needs them.
> > Third, you should check for pthread_kill in -lpthread, if the
> > function is not available when you use -pthread (Solaris,
> > Tru64, probably other O/S as well). Why not check for
> > pthread_create? Because on Tru64, -lpthread does not contain
> > pthread_create.
>
> Ouch. Is it a macro or something?
Yes, IIRC it is defined to _pthread_create. Don't ask me why. :)
Of course, you could include <pthread.h> first and check for
pthread_create(). In TSRM, I chose to go the way of least
resistance and pick a function which is always available.
> So there are two ways I can go about adding these changes. I can
> either try to cover all OSes without OS detection. (-D_REENTRANT
> -D_POSIX_PTHREAD_SEMANTICS -D...) or just bite the bullet and check
> the OS first. I guess we should do the latter.
I couldn't verify this yet, but SCO seems to be have problems
with _REENTRANT. So, at least on that platform _REENTRANT
should not be defined.
> Are there any good autoconf macros that have all this stuff
> encapsulated already?
None which perform OS-specific checks.
--
Regards,
Sascha Schumann
Consultant
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by Manoj Kasichainula <ma...@io.com>.
On Tue, Dec 21, 1999 at 05:25:05PM +0100, Sascha Schumann wrote:
> Well, it is not that easy. First, -pthread isn't relevant to
> the compile stage. It should be put into LDFLAGS (it causes
> -lc_r or -lpthread on FreeBSD or Linux, respectively).
On Linux systems that I've checked, -pthread implies -lpthread, and it
seems to be working for me in just the CFLAGS. In fact, it's curious
that nothing is needed in LDFLAGS; I guess that since gcc is used as
the linker, autoconf is also appending CFLAGS. *shrug*
> Second, a number of macros are needed. On Linux, it is
> _REENTRANT (see <features.h>).
-pthread also turns on -D_REENTRANT on my Linux box.
> On FreeBSD, no special flags are needed (AFAIK; the fact that
> the thread-safe PHP binary builds flawlessly supports this.
Actually, I don't think not including -D_REENTRANT will make any
compiles fail if you try compiling threaded code; it will just make
your code not work :(. If FreeBSD doesn't also add an implied
-D_REENTRANT, then yeah, we should do so.
> On Solaris, you need _POSIX_PTHREAD_SEMANTICS.
Noted.
> Third, you should check for pthread_kill in -lpthread, if the
> function is not available when you use -pthread (Solaris,
> Tru64, probably other O/S as well). Why not check for
> pthread_create? Because on Tru64, -lpthread does not contain
> pthread_create.
Ouch. Is it a macro or something?
So there are two ways I can go about adding these changes. I can
either try to cover all OSes without OS detection. (-D_REENTRANT
-D_POSIX_PTHREAD_SEMANTICS -D...) or just bite the bullet and check
the OS first. I guess we should do the latter.
Are there any good autoconf macros that have all this stuff
encapsulated already?
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by Sascha Schumann <sa...@schumann.cx>.
On Mon, Dec 20, 1999 at 01:24:52PM -0600, Manoj Kasichainula wrote:
> On Mon, Dec 20, 1999 at 02:48:40PM -0500, Ryan Bloom wrote:
> > I may be wrong, but I am reasonably sure that the configure script doesn't
> > get the correct CFLAGS or LIBS for pthreads on FreeBSD. This is a known
> > issue, and it needs to be fixed. :)
>
> The pthreads check for Apache is in src/modules/mpm/config.m4. It's
> pretty simplistic still. Linux only needs -pthread on everything; ISTR
> that FreeBSD needed some extra -D's (bleh).
Well, it is not that easy. First, -pthread isn't relevant to
the compile stage. It should be put into LDFLAGS (it causes
-lc_r or -lpthread on FreeBSD or Linux, respectively).
Second, a number of macros are needed. On Linux, it is
_REENTRANT (see <features.h>). On FreeBSD, no special flags
are needed (AFAIK; the fact that the thread-safe PHP binary
builds flawlessly supports this. <math.h> references
_REENTRANT, so you might want to set it anyway). On Solaris,
you need _POSIX_PTHREAD_SEMANTICS.
Third, you should check for pthread_kill in -lpthread, if the
function is not available when you use -pthread (Solaris,
Tru64, probably other O/S as well). Why not check for
pthread_create? Because on Tru64, -lpthread does not contain
pthread_create.
--
Regards,
Sascha Schumann
Consultant
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by Manoj Kasichainula <ma...@io.com>.
On Mon, Dec 20, 1999 at 02:48:40PM -0500, Ryan Bloom wrote:
> I may be wrong, but I am reasonably sure that the configure script doesn't
> get the correct CFLAGS or LIBS for pthreads on FreeBSD. This is a known
> issue, and it needs to be fixed. :)
The pthreads check for Apache is in src/modules/mpm/config.m4. It's
pretty simplistic still. Linux only needs -pthread on everything; ISTR
that FreeBSD needed some extra -D's (bleh).
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by rb...@apache.org.
> I don't like makefiles that hide stuff. In my experience, if it works
> no-one cares how much output there is, and if it doesn't, why hide the
> useful stuff?
I didn't do it. I went away for a while, and it was done. I'll add some
output tomorrow sometime unless you get to it first. It's easy enough to
do. :-)
> As you will have spotted by now, 3 is my general choice, but I do try to
> find out wtf is going on before I break stuff :-)
I have very few worries about you breaking things. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@ntrnet.net
6209 H Shanda Dr.
Raleigh, NC 27609 Ryan Bloom -- thinker, adventurer, artist,
writer, but mostly, friend.
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@apache.org wrote:
>
> > Well, that's partly what puzzles me. I don't see any merging.
>
> The merging is done silently.
I don't like makefiles that hide stuff. In my experience, if it works
no-one cares how much output there is, and if it doesn't, why hide the
useful stuff?
> Basically, we copy all of the object files
> into objs/ and then create the library from those files. I have committed
> changes that stop us from building the individual libraries.
Cool.
> > That's not the problem - the unresolved stuff is exclusively APR
> > functions.
>
> I haven't tested on FreeBSD for a few weeks. You have three options,
> 1) send me the output of your build and let me see if I can figure it
> out.
> 2) wait and I will test it on a FreeBSD box tomorrow and commit the
> problems.
> 3) Fix it yourself.
As you will have spotted by now, 3 is my general choice, but I do try to
find out wtf is going on before I break stuff :-)
In this case I'll probably get hit by 2 involuntarily!
> There may be some functions not built on FreeBSD, but I don't personally
> know of any.
Nor I. That doesn't seem to be the root problem.
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by rb...@apache.org.
> Well, that's partly what puzzles me. I don't see any merging.
The merging is done silently. Basically, we copy all of the object files
into objs/ and then create the library from those files. I have committed
changes that stop us from building the individual libraries.
> That's not the problem - the unresolved stuff is exclusively APR
> functions.
I haven't tested on FreeBSD for a few weeks. You have three options,
1) send me the output of your build and let me see if I can figure it
out.
2) wait and I will test it on a FreeBSD box tomorrow and commit the
problems.
3) Fix it yourself.
There may be some functions not built on FreeBSD, but I don't personally
know of any.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@ntrnet.net
6209 H Shanda Dr.
Raleigh, NC 27609 Ryan Bloom -- thinker, adventurer, artist,
writer, but mostly, friend.
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by Ben Laurie <be...@algroup.co.uk>.
Ryan Bloom wrote:
>
> > > APR hasn't built a dozen different libraries for a long time. We are only
> > > building the one libapr.a.
> >
> > Should I send a log? Perhaps there's a step missing in the build? I
> > dunno. I'm confused.
>
> I don't know either. I'll look into it. It's possible that we are
> actually building all of the libraries and then merging them all together
> into one big one. We shouldn't be, but I never checked the commit that
> got us to build one library.
Well, that's partly what puzzles me. I don't see any merging.
> > > I have the code working just fine on Linux and
> > > Windows. If you are using the prefork MPM, you have to specify
> > > LIBS="-lpthread".
> >
> > I let it choose (it chose threaded).
>
> I may be wrong, but I am reasonably sure that the configure script doesn't
> get the correct CFLAGS or LIBS for pthreads on FreeBSD. This is a known
> issue, and it needs to be fixed. :)
That's not the problem - the unresolved stuff is exclusively APR
functions.
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> > APR hasn't built a dozen different libraries for a long time. We are only
> > building the one libapr.a.
>
> Should I send a log? Perhaps there's a step missing in the build? I
> dunno. I'm confused.
I don't know either. I'll look into it. It's possible that we are
actually building all of the libraries and then merging them all together
into one big one. We shouldn't be, but I never checked the commit that
got us to build one library.
> > I have the code working just fine on Linux and
> > Windows. If you are using the prefork MPM, you have to specify
> > LIBS="-lpthread".
>
> I let it choose (it chose threaded).
I may be wrong, but I am reasonably sure that the configure script doesn't
get the correct CFLAGS or LIBS for pthreads on FreeBSD. This is a known
issue, and it needs to be fixed. :)
> Consider me porting and modifying!
Cool.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709
Come to the first official Apache Software Foundation
Conference! <http://ApacheCon.Com/>
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> > APR hasn't built a dozen different libraries for a long time. We are only
> > building the one libapr.a.
>
> Should I send a log? Perhaps there's a step missing in the build? I
> dunno. I'm confused.
I don't know either. I'll look into it. It's possible that we are
actually building all of the libraries and then merging them all together
into one big one. We shouldn't be, but I never checked the commit that
got us to build one library.
> > I have the code working just fine on Linux and
> > Windows. If you are using the prefork MPM, you have to specify
> > LIBS="-lpthread".
>
> I let it choose (it chose threaded).
I may be wrong, but I am reasonably sure that the configure script doesn't
get the correct CFLAGS or LIBS for pthreads on FreeBSD. This is a known
issue, and it needs to be fixed. :)
> Consider me porting and modifying!
Cool.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709
Come to the first official Apache Software Foundation
Conference! <http://ApacheCon.Com/>
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by Ben Laurie <be...@algroup.co.uk>.
Ryan Bloom wrote:
>
> > OK, but the config.cache should still be removed, surely?
> >
> > Also, BTW, the current version completely fails to build for me (lots of
> > unresolved externals) - what's the current recommended build path?
> >
> > I'm slightly puzzled by what's going on with APR - it seems to build a
> > dozen different libraries, but Apache only seems to use one. What am I
> > missing?
>
> APR hasn't built a dozen different libraries for a long time. We are only
> building the one libapr.a.
Should I send a log? Perhaps there's a step missing in the build? I
dunno. I'm confused.
> What platform are you on?
FreeBSD.
> I have the code working just fine on Linux and
> Windows. If you are using the prefork MPM, you have to specify
> LIBS="-lpthread".
I let it choose (it chose threaded).
> If you are on any other platform, you are on your own.
I'm _always_ on my own :-)
> The configure script has basically been written on Linux, and it is
> assumed it will be modified as we port 2.0.
Consider me porting and modifying!
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by Ben Laurie <be...@algroup.co.uk>.
Ryan Bloom wrote:
>
> > OK, but the config.cache should still be removed, surely?
> >
> > Also, BTW, the current version completely fails to build for me (lots of
> > unresolved externals) - what's the current recommended build path?
> >
> > I'm slightly puzzled by what's going on with APR - it seems to build a
> > dozen different libraries, but Apache only seems to use one. What am I
> > missing?
>
> APR hasn't built a dozen different libraries for a long time. We are only
> building the one libapr.a.
Should I send a log? Perhaps there's a step missing in the build? I
dunno. I'm confused.
> What platform are you on?
FreeBSD.
> I have the code working just fine on Linux and
> Windows. If you are using the prefork MPM, you have to specify
> LIBS="-lpthread".
I let it choose (it chose threaded).
> If you are on any other platform, you are on your own.
I'm _always_ on my own :-)
> The configure script has basically been written on Linux, and it is
> assumed it will be modified as we port 2.0.
Consider me porting and modifying!
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> OK, but the config.cache should still be removed, surely?
>
> Also, BTW, the current version completely fails to build for me (lots of
> unresolved externals) - what's the current recommended build path?
>
> I'm slightly puzzled by what's going on with APR - it seems to build a
> dozen different libraries, but Apache only seems to use one. What am I
> missing?
APR hasn't built a dozen different libraries for a long time. We are only
building the one libapr.a.
What platform are you on? I have the code working just fine on Linux and
Windows. If you are using the prefork MPM, you have to specify
LIBS="-lpthread". If you are on any other platform, you are on your own.
The configure script has basically been written on Linux, and it is
assumed it will be modified as we port 2.0.
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: cvs commit: apache-2.0/src buildconf configure.in
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> OK, but the config.cache should still be removed, surely?
>
> Also, BTW, the current version completely fails to build for me (lots of
> unresolved externals) - what's the current recommended build path?
>
> I'm slightly puzzled by what's going on with APR - it seems to build a
> dozen different libraries, but Apache only seems to use one. What am I
> missing?
APR hasn't built a dozen different libraries for a long time. We are only
building the one libapr.a.
What platform are you on? I have the code working just fine on Linux and
Windows. If you are using the prefork MPM, you have to specify
LIBS="-lpthread". If you are on any other platform, you are on your own.
The configure script has basically been written on Linux, and it is
assumed it will be modified as we port 2.0.
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: cvs commit: apache-2.0/src buildconf configure.in
Posted by Ben Laurie <be...@algroup.co.uk>.
manoj@hyperreal.org wrote:
>
> manoj 99/12/19 17:54:40
>
> Modified: src buildconf configure.in
> Log:
> Make Apache's configure script run APR's.
OK, but the config.cache should still be removed, surely?
Also, BTW, the current version completely fails to build for me (lots of
unresolved externals) - what's the current recommended build path?
I'm slightly puzzled by what's going on with APR - it seems to build a
dozen different libraries, but Apache only seems to use one. What am I
missing?
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: cvs commit: apache-2.0/src buildconf configure.in
Posted by Ben Laurie <be...@algroup.co.uk>.
manoj@hyperreal.org wrote:
>
> manoj 99/12/19 17:54:40
>
> Modified: src buildconf configure.in
> Log:
> Make Apache's configure script run APR's.
OK, but the config.cache should still be removed, surely?
Also, BTW, the current version completely fails to build for me (lots of
unresolved externals) - what's the current recommended build path?
I'm slightly puzzled by what's going on with APR - it seems to build a
dozen different libraries, but Apache only seems to use one. What am I
missing?
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi