Graham Leggett wrote:
> William A. Rowe, Jr. wrote:
>
>> I wouldn't mind an rpm spec file for 0.9.6 either. +1
>
> There is an outstanding vote in httpd v2.0's STATUS for fixing the spec
> file in httpd v2.0.49 (v2.1.0-dev has been fixed). What I'm keen to see
> though is a separation of RPM pac
At 04:04 PM 6/22/2004, Graham Leggett wrote:
>William A. Rowe, Jr. wrote:
>
>>I wouldn't mind an rpm spec file for 0.9.6 either. +1
>
>There is an outstanding vote in httpd v2.0's STATUS for fixing the spec file
>in httpd v2.0.49 (v2.1.0-dev has been fixed). What I'm keen to see though is a
>sep
At 06:02 PM 6/22/2004, Graham Leggett wrote:
>Joe Orton wrote:
>
>>You need to screw around a bit to make some of the files relocate
>>properly; look at the %install of the Fedora apr.spec, it's handled
>>there.
>
>I've tried to take Fedora development apr-util's spec file and get that to
>work, b
Hi all,
Been bashing away at getting apr-util to build, but it seems still too
tightly coupled with apr to be built separately.
There are two problems with the build so far.
The files apr_common.m4, gen-build.py, make_exports.awk, install.sh and
config.sub from apr are needed by apr-util. apr-ut
William A. Rowe, Jr. wrote:
Silly question, are you ./buildconf'ing --with-apr=/xxx
It's first a buildconf option.
Yes, but the build process tries to find the build files in /usr/build,
which does not exist.
Idealy we need to be able to specify the ./build directory separately
from the include
On Wed, Jun 23, 2004 at 04:01:18AM +0200, Graham Leggett wrote:
> Hi all,
>
> Been bashing away at getting apr-util to build, but it seems still too
> tightly coupled with apr to be built separately.
>
> There are two problems with the build so far.
>
> The files apr_common.m4, gen-build.py, ma
Joe Orton wrote:
gen-build.py, apr_common.m4 and config.sub are surely only needed if you
run ./buildconf? That shouldn't be necessary for apr-util.
Ok... this explains a bit, will take it out and see if I get any luck.
The second problem is in ./configure and Makefile.in. The build scripts
looks
On Wed, Jun 23, 2004 at 12:14:47PM +0200, Graham Leggett wrote:
> Joe Orton wrote:
> >>The second problem is in ./configure and Makefile.in. The build scripts
> >>looks for the above files in the source code directory for apr using this:
> >>
> >>configure:APR_SOURCE_DIR="`$apr_config --srcdir
Joe Orton wrote:
I think the correct solution is to:
1) make the apr "make install" install those .awk files into the
installbuilddir directory.
2) replace use of the `apr-config --srcdir` with `apr-config
--installbuilddir` in apr-util's configure & Makefile.
That's exactly it - thanks! I didn't
On Wed, Jun 23, 2004 at 01:31:33PM +0200, Graham Leggett wrote:
> Joe Orton wrote:
>
> >I think the correct solution is to:
> >
> >1) make the apr "make install" install those .awk files into the
> >installbuilddir directory.
> >
> >2) replace use of the `apr-config --srcdir` with `apr-config
> >
On Wed, Jun 23, 2004 at 01:00:40PM +0100, Joe Orton wrote:
> On Wed, Jun 23, 2004 at 01:31:33PM +0200, Graham Leggett wrote:
> > Joe Orton wrote:
> >
> > >I think the correct solution is to:
> > >
> > >1) make the apr "make install" install those .awk files into the
> > >installbuilddir directory
Joe Orton wrote:
[resend in case it gets through quicker]
On Tue, Jun 22, 2004 at 10:42:23AM -, [EMAIL PROTECTED] wrote:
--- apr_xml.c 14 Jun 2004 15:13:14 - 1.30
+++ apr_xml.c 22 Jun 2004 10:42:23 - 1.31
@@ -30,17 +30,23 @@
#include "expat.h"
#endif
+#include "ascii.h"
+
[EMAIL PROTECTED] wrote:
Log:
Revert previous change (effectively) to fix VPATH build with in-tree
apr and apr-util.
* build/apu-conf.m4: Export APR srcdir again.
* Makefile.in: Use APR srcdir for APR_BUILD_DIR.
Is there a better fix for this?
apr-util cannot currently be built with
Joe Orton wrote:
And then I reverted them, since they broke VPATH builds with in-tree
apr/apr-util. apr-util needs to find both apr_rules.mk and the awk
scripts, for the in-tree build, the former lies in a VPATH build
directory, the latter in the VPATH source directory; `apr-config
--installbuildd
Would someone please investigate:
apr\random\unix\sha2.c(461) : warning C4244: '=' : conversion from 'unsigned
__int64 ' to 'unsigned int ', possible loss of data
apr\random\unix\sha2.c(507) : warning C4244: '=' : conversion from 'unsigned
__int64 ' to 'unsigned int ', possible loss of data
apr\
Do we know what broke here from history? Was the pool arg added
(breaking binary compat) in the 0.9 tree, or was this backing out a
bugged change?
At 01:00 PM 6/23/2004, [EMAIL PROTECTED] wrote:
>stoddard2004/06/23 11:00:02
>
> Modified:xlateTag: APU_0_9_BRANCH xlate.c
> Log:
> Fix
This patch broke the build:
http://cvs.apache.org/viewcvs.cgi/apr-util/xlate/xlate.c?r1=1.17.2.1&r2=1.17.2.2
API to apr_iconv_open/close was changed about three years ago by this patch:
http://cvs.apache.org/viewcvs.cgi/apr-iconv/lib/iconv.h?r1=1.7&r2=1.8
I have no idea why Joe's patch was using an
On Wed, Jun 23, 2004 at 03:33:27PM -0400, Bill Stoddard wrote:
> This patch broke the build:
> http://cvs.apache.org/viewcvs.cgi/apr-util/xlate/xlate.c?r1=1.17.2.1&r2=1.17.2.2
>
> API to apr_iconv_open/close was changed about three years ago by this patch:
> http://cvs.apache.org/viewcvs.cgi/apr-i
I'd like to suggest we hold our horses on apr-util and apr-iconv 1.0 - they
are seperate subsets with their own set of issues.
APR 1.0 does not require apr-util or apr-iconv, there is no dependency.
So no holdup of David's plans.
I'm proposing we switch around apr-iconv's interface to:
1) change
On Wed, Jun 23, 2004 at 06:46:07PM +0200, Graham Leggett wrote:
> Joe Orton wrote:
>
> >And then I reverted them, since they broke VPATH builds with in-tree
> >apr/apr-util. apr-util needs to find both apr_rules.mk and the awk
> >scripts, for the in-tree build, the former lies in a VPATH build
>
At 02:33 PM 6/23/2004, Bill Stoddard wrote:
>This patch broke the build:
>http://cvs.apache.org/viewcvs.cgi/apr-util/xlate/xlate.c?r1=1.17.2.1&r2=1.17.2.2
>
>API to apr_iconv_open/close was changed about three years ago by this patch:
>http://cvs.apache.org/viewcvs.cgi/apr-iconv/lib/iconv.h?r1=1.7&
> I'd like to suggest we hold our horses on apr-util and apr-iconv 1.0 -
they
> are seperate subsets with their own set of issues.
>
> APR 1.0 does not require apr-util or apr-iconv, there is no dependency.
> So no holdup of David's plans.
Well, I'd agree on apr-iconv (haven't even rolled a 1.0 rc
22 matches
Mail list logo