apr_hash.c has a very obscure bug in it, though I'm very surprised nobody
has been bitten by it before. It is possible, when expanding the table,
to use an old pointer and overwrite the hash entry value upon return from
find_entry. Anyway, this small patch fixes it. I have a testhash.c for
No.
We run xml/expat/configure, and it produces that Makefile. APRUTIL shouldn't
be doing this. Please back out this change.
-g
On Fri, Mar 09, 2001 at 08:29:04AM -, [EMAIL PROTECTED] wrote:
martin 01/03/09 00:29:03
Modified:.configure.in
Log:
Make Makefile in
This change gets things building for me on BeOS...
david
No.
We run xml/expat/configure, and it produces that Makefile. APRUTIL
shouldn't
be doing this. Please back out this change.
-g
On Fri, Mar 09, 2001 at 08:29:04AM -, [EMAIL PROTECTED] wrote:
martin 01/03/09 00:29:03
Boolean switches should use AC_ARG_ENABLE(). AC_ARG_WITH is to allow you to
specify configure with this package. The code below should fall out
simply as:
AC_ARG_ENABLE(sendfile, [ --enable-sendfile Enable or disable sendfile support]
[ if test $enable_sendfile = yes; then
sendfile=1
Ah. I missed this because during my testing, I was doing builds manually
within xml/expat. I never did a complete from-scratch build.
thx!
-g
On Thu, Mar 08, 2001 at 06:30:33PM -, [EMAIL PROTECTED] wrote:
rbb 01/03/08 10:30:30
Modified:xml Makefile.in
Log:
Always
On Fri, Mar 09, 2001 at 05:06:25AM -0800, Greg Stein wrote:
No.
We run xml/expat/configure, and it produces that Makefile. APRUTIL shouldn't
be doing this. Please back out this change.
That is not really true. It definitely did not generate the Makefile,
that's why I added the patch in the
I don't think it has anything to do with mechanics, nor will throwing more
process at the problem fix it. (more process will simply bog down what we
can accomplish)
No... the problem is about perception. The rate of change recently has just
been quite high. It just isn't very conceivable to make
I have found recently, that buildconf doesn't really do what you expect in
a lot of cases. Namely, it doesn't tend to traverse into srclib/apr and
srclib/apr-util, and run those buildconf's. Try running those manually
right now. I was going to investigate further before posting the bug, but
On Fri, Mar 09, 2001 at 03:01:36PM +0100, Martin Kraemer wrote:
On Fri, Mar 09, 2001 at 05:06:25AM -0800, Greg Stein wrote:
No.
We run xml/expat/configure, and it produces that Makefile. APRUTIL shouldn't
be doing this. Please back out this change.
That is not really true. It
That is probably the stupid dependency stuff in build2.mk. httpd's buildconf
should unconditionally recurse.
But Martin's error is something else, I believe (see other note). I'm
testing a fix now.
Cheers,
-g
On Fri, Mar 09, 2001 at 06:25:40AM -0800, [EMAIL PROTECTED] wrote:
I have found
On Fri, 9 Mar 2001, Greg Stein wrote:
That is probably the stupid dependency stuff in build2.mk. httpd's buildconf
should unconditionally recurse.
But Martin's error is something else, I believe (see other note). I'm
testing a fix now.
Okay, and that fix needs to go in (I mentioned it in my
On Sat, 10 Mar 2001, Luke Kenneth Casson Leighton wrote:
On Fri, 9 Mar 2001, Greg Stein wrote:
I don't think it has anything to do with mechanics, nor will throwing more
process at the problem fix it. (more process will simply bog down what we
can accomplish)
...? if nothing else:
cd
On Fri, Mar 09, 2001 at 06:54:29AM -0800, [EMAIL PROTECTED] wrote:
On Sat, 10 Mar 2001, Luke Kenneth Casson Leighton wrote:
On Fri, 9 Mar 2001, Greg Stein wrote:
I don't think it has anything to do with mechanics, nor will throwing more
process at the problem fix it. (more process will
Hi,
I have some problems with the Makefile on apr-util/xml/expat.
The option -Wp,-MD,.deps/$(*F).pp is no understand neither on Solaris
nor on ReliantUnix.
On Solaris the fix is to use:
+++
$(LTCOMPILE) -xM $ .deps/$(*F).pp;
\
$(LTCOMPILE) -c
$
Tru64 is busted with this too, though when I do make from toplevel,
link of dftables failes because libexpat.la does not exist.
A make from xml just says Making all in expat
A make from xml/expat does nothing. Oh, I have to touch config.status
for some reason.
When I do make from
Fixed.
Cheers,
-g
On Fri, Mar 09, 2001 at 11:22:04AM -0500, Jeff Trawick wrote:
Tru64 is busted with this too, though when I do make from toplevel,
link of dftables failes because libexpat.la does not exist.
A make from xml just says Making all in expat
A make from xml/expat does nothing.
16 matches
Mail list logo
