You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2001/06/26 20:40:04 UTC

ra_dav wackies

Hey gstein --

I just checked out a working copy from Apache, and did an update:

[sussman@newt:~/projects/test/nwc]$ svn up
?  ./.svn_update.7180.00001.ra_dav


Heh, now that we have that new super-special reporting code, it was
able to detect your oh-so-sneaky-and-hidden temp file.  I figured it's
a deep dark secret, since it was gone when the update finished.  :-)

Seriously, though, we should figure out what to do about this.  The
user shouldn't be seeing these files.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Compile issues

Posted by Karl Fogel <kf...@collab.net>.
A suggestion:

I've had weird APR build problems before too.  Usually I just

   cd apr/
   ./buildconf
   ./configure
   make
   cd ..

and try building Subversion again, and it works.  Wish I knew why.
Good luck...

-K


"Julian Fitzell" <ju...@beta4.com> writes:
> Came back to this list after an absence and in trying to compile the code got the following errors.
> 
> In file included from subversion/mod_dav_svn/activity.c:27:
> subversion/mod_dav_svn/dav_svn.h:287: parse error before `*'
> subversion/mod_dav_svn/activity.c: In function `dav_svn_get_txn':
> subversion/mod_dav_svn/activity.c:44: warning: passing arg 4 of `apr_dbm_open' makes pointer from integer without a cast
> subversion/mod_dav_svn/activity.c:44: too many arguments to function `apr_dbm_open'
> subversion/mod_dav_svn/activity.c: In function `dav_svn_store_activity':
> subversion/mod_dav_svn/activity.c:83: warning: passing arg 4 of `apr_dbm_open' makes pointer from integer without a cast
> subversion/mod_dav_svn/activity.c:83: too many arguments to function `apr_dbm_open'
> make: *** [subversion/mod_dav_svn/activity.lo] Error 1
> 
> I've tried doing CVS updates over the last few weeks to see if the problem is corrected but no luck.  I also just tried checking it out from scratch and using the new Neon but that didn't help either.  I can't even find the function defintion for apr_dbm_open anywhere except the file that has the error with a grep through the source tree.
> 
> Is everyone else able to build at the moment?  Does anyone have any suggestions?... I'm at a loss...
> 
> Thanks,
> 
> Julian
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Compile issues

Posted by Julian Fitzell <ju...@beta4.com>.
Yeah, that's what I'm trying to do... I compiled Apache 2 from CVS (about a week and a half ago) using the following configure line:

./configure  --prefix=/usr/local/apache2 --enable-so --enable-modules=most --enable-mods-shared=max

I used apr and apr-utils from CVS in compiling Apache.  Apache compiled fine and is installed.

I configured subversion as follows:

./configure  --with-apxs=/usr/local/apache2/bin/apxs --enable-debug

I also tried originally without --enable-debug.  I'm using apr from CVS from yesterday or so and Neon 0.15.3


I hadn't found notes/dav_setup.txt but I looked at it now and I'm pretty sure I was doing everything in there.  If necessary, I may try starting from scratch and following it step by step.

Thanks for all your help guys, hopefully my config lines will give a clue...

Julian

On 27/06/01 at 12:09 PM Ben Collins-Sussman wrote:

>Greg Stein <gs...@lyra.org> writes:
>
>> Nobody has asked the key question: what version of Apache are you trying
>to
>> build against?
>> 
>> You need the CVS version of Apache 2.0 (the httpd-2.0 repository). I
>believe
>> a 2.0.19 (alpha) will pop out of the ASF "soon" and that should be
>> sufficient. But nothing before that.
>
>Yeah.... and do you really want to be building mod_dav_svn?  Not that
>there's anything wrong with it, but it implies that you're attempting
>to set up a Subversion-aware Apache on your system.  If this is what
>you want, then make sure you're following the directions in
>notes/dav_setup.txt.
>
>If this isn't what you want, then show us your "configure" switches. :-)




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Compile issues

Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:

> Nobody has asked the key question: what version of Apache are you trying to
> build against?
> 
> You need the CVS version of Apache 2.0 (the httpd-2.0 repository). I believe
> a 2.0.19 (alpha) will pop out of the ASF "soon" and that should be
> sufficient. But nothing before that.

Yeah.... and do you really want to be building mod_dav_svn?  Not that
there's anything wrong with it, but it implies that you're attempting
to set up a Subversion-aware Apache on your system.  If this is what
you want, then make sure you're following the directions in
notes/dav_setup.txt.

If this isn't what you want, then show us your "configure" switches. :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Compile issues

Posted by Greg Stein <gs...@lyra.org>.
Nobody has asked the key question: what version of Apache are you trying to
build against?

You need the CVS version of Apache 2.0 (the httpd-2.0 repository). I believe
a 2.0.19 (alpha) will pop out of the ASF "soon" and that should be
sufficient. But nothing before that.

(well, maybe the 2.0.18 alpha tarball)

Cheers,
-g

On Tue, Jun 26, 2001 at 11:41:18PM -0700, Julian Fitzell wrote:
> Hmm... I'm building it on RedHat 7.0 (i386).
> 
> Karl's suggestion didn't seem to help because apr seems to compile fine either way.
> 
> I tried doing a the "make CFLAGS=-E > foo.e" and got very little output in the file (presumably because everything was up to date).  So I did a make clean and then tried again and got a bunch of errors.  Then I realized I actually needed to do "make CFLAGS="-E -I/software/subversion/expat-lite -I.." > foo.e"
> 
> This resulted in a whole bunch of warnings saying "warning: pasting would not give a valid preprocessing token" in a bunch of neon files and then the error:
> 
> mm_global.lo: file not recognized: File format not recognized
> collect2: ld returned 1 exit status
> make[4]: *** [libmm.la] Error 1
> make[3]: *** [build-mm] Error 2
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [external-all] Error 1
> 
> Looking at foo.e, it does not contain any mention of typedefs or anything.
> 
> If I do a "make" it doesn't work now, but if I do a "make clean" and then another "make" I get back to the original error about apr_dbm_open.
> 
> Julian
> 
> 
> 
> On 26/06/01 at 6:19 PM Mo DeJong wrote:
> 
> >On Tue, 26 Jun 2001, Julian Fitzell wrote:
> >
> >> Hi,
> >> 
> >> Came back to this list after an absence and in trying to compile the
> >code got the following errors.
> >> 
> >> In file included from subversion/mod_dav_svn/activity.c:27:
> >> subversion/mod_dav_svn/dav_svn.h:287: parse error before `*'
> >
> >Either dav_error or ap_filter_t is not defined at that point.
> >What system are you building on? You could try a quick
> >"make CFLAGS=-E > foo.e" and then look in the processed
> >.e file to see if you can find a typedef for both dav_error
> >and ap_filter_t.
> >
> >> Is everyone else able to build at the moment?
> >
> >The current tree builds for me under RH 6.2 with neon 0.15.3.
> >
> >I hope that helps
> >Mo
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> >For additional commands, e-mail: dev-help@subversion.tigris.org
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Compile issues

Posted by Julian Fitzell <ju...@beta4.com>.
Hmm... I'm building it on RedHat 7.0 (i386).

Karl's suggestion didn't seem to help because apr seems to compile fine either way.

I tried doing a the "make CFLAGS=-E > foo.e" and got very little output in the file (presumably because everything was up to date).  So I did a make clean and then tried again and got a bunch of errors.  Then I realized I actually needed to do "make CFLAGS="-E -I/software/subversion/expat-lite -I.." > foo.e"

This resulted in a whole bunch of warnings saying "warning: pasting would not give a valid preprocessing token" in a bunch of neon files and then the error:

mm_global.lo: file not recognized: File format not recognized
collect2: ld returned 1 exit status
make[4]: *** [libmm.la] Error 1
make[3]: *** [build-mm] Error 2
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [external-all] Error 1

Looking at foo.e, it does not contain any mention of typedefs or anything.

If I do a "make" it doesn't work now, but if I do a "make clean" and then another "make" I get back to the original error about apr_dbm_open.

Julian



On 26/06/01 at 6:19 PM Mo DeJong wrote:

>On Tue, 26 Jun 2001, Julian Fitzell wrote:
>
>> Hi,
>> 
>> Came back to this list after an absence and in trying to compile the
>code got the following errors.
>> 
>> In file included from subversion/mod_dav_svn/activity.c:27:
>> subversion/mod_dav_svn/dav_svn.h:287: parse error before `*'
>
>Either dav_error or ap_filter_t is not defined at that point.
>What system are you building on? You could try a quick
>"make CFLAGS=-E > foo.e" and then look in the processed
>.e file to see if you can find a typedef for both dav_error
>and ap_filter_t.
>
>> Is everyone else able to build at the moment?
>
>The current tree builds for me under RH 6.2 with neon 0.15.3.
>
>I hope that helps
>Mo
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Compile issues

Posted by Mo DeJong <md...@cygnus.com>.
On Tue, 26 Jun 2001, Julian Fitzell wrote:

> Hi,
> 
> Came back to this list after an absence and in trying to compile the code got the following errors.
> 
> In file included from subversion/mod_dav_svn/activity.c:27:
> subversion/mod_dav_svn/dav_svn.h:287: parse error before `*'

Either dav_error or ap_filter_t is not defined at that point.
What system are you building on? You could try a quick
"make CFLAGS=-E > foo.e" and then look in the processed
.e file to see if you can find a typedef for both dav_error
and ap_filter_t.

> Is everyone else able to build at the moment?

The current tree builds for me under RH 6.2 with neon 0.15.3.

I hope that helps
Mo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Compile issues

Posted by Julian Fitzell <ju...@beta4.com>.
Hi,

Came back to this list after an absence and in trying to compile the code got the following errors.

In file included from subversion/mod_dav_svn/activity.c:27:
subversion/mod_dav_svn/dav_svn.h:287: parse error before `*'
subversion/mod_dav_svn/activity.c: In function `dav_svn_get_txn':
subversion/mod_dav_svn/activity.c:44: warning: passing arg 4 of `apr_dbm_open' makes pointer from integer without a cast
subversion/mod_dav_svn/activity.c:44: too many arguments to function `apr_dbm_open'
subversion/mod_dav_svn/activity.c: In function `dav_svn_store_activity':
subversion/mod_dav_svn/activity.c:83: warning: passing arg 4 of `apr_dbm_open' makes pointer from integer without a cast
subversion/mod_dav_svn/activity.c:83: too many arguments to function `apr_dbm_open'
make: *** [subversion/mod_dav_svn/activity.lo] Error 1

I've tried doing CVS updates over the last few weeks to see if the problem is corrected but no luck.  I also just tried checking it out from scratch and using the new Neon but that didn't help either.  I can't even find the function defintion for apr_dbm_open anywhere except the file that has the error with a grep through the source tree.

Is everyone else able to build at the moment?  Does anyone have any suggestions?... I'm at a loss...

Thanks,

Julian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra_dav wackies

Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jun 27, 2001 at 11:47:54AM +0100, Joe Orton wrote:
> On Wed, Jun 27, 2001 at 03:42:11AM -0700, Greg Stein wrote:
> ...
> > Okay... that file is for the "report" that we send to the server. I think
> > there was going to be an API for writing bits, rather than the whole thing.
> > I don't remember and will need to look at the Neon API again. I also had
> > some changes in mind for Neon that I volunteered for a couple months ago(!)
> > but Joe may have already done them. Anyway... I believe we may be able to
> > toss the file. If not, we may want to look at using SVN/tmp/ to hold it.
> 
> I looked at this and I wasn't quite sure why the REPORT body had to be
> buffered to a file, it looked like it was just going to contain a few
> lines of XML. Could it be buffered in memory instead? (I can patch that
> if so)

The report body is arbitrary size. It depends on the number of differences
in versions you have in your WC. If you have a large WC with a large
variation in versions, then the report is going to be quite large.

> If not, it will be pretty difficult to re-do neon to allow
> caller-pushing request bodies through. (neon can do neon-pulls request
> body and caller-pulls response body now though.)

Okay, no problem. We can continue to buffer. As I mentioned in a comment in
that code, we can also spin up a thread and use a pipe between the
client-push and the neon-pull. (if we really dislike the buffering for some
reason; my tendency is to avoid the thread)

Cheers,
-g

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra_dav wackies

Posted by Joe Orton <jo...@btconnect.com>.
On Wed, Jun 27, 2001 at 03:42:11AM -0700, Greg Stein wrote:
...
> Okay... that file is for the "report" that we send to the server. I think
> there was going to be an API for writing bits, rather than the whole thing.
> I don't remember and will need to look at the Neon API again. I also had
> some changes in mind for Neon that I volunteered for a couple months ago(!)
> but Joe may have already done them. Anyway... I believe we may be able to
> toss the file. If not, we may want to look at using SVN/tmp/ to hold it.

I looked at this and I wasn't quite sure why the REPORT body had to be
buffered to a file, it looked like it was just going to contain a few
lines of XML. Could it be buffered in memory instead? (I can patch that
if so)

If not, it will be pretty difficult to re-do neon to allow
caller-pushing request bodies through. (neon can do neon-pulls request
body and caller-pulls response body now though.)

joe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra_dav wackies

Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jun 26, 2001 at 03:40:04PM -0500, Ben Collins-Sussman wrote:
> Hey gstein --
> 
> I just checked out a working copy from Apache, and did an update:
> 
> [sussman@newt:~/projects/test/nwc]$ svn up
> ?  ./.svn_update.7180.00001.ra_dav
> 
> 
> Heh, now that we have that new super-special reporting code, it was
> able to detect your oh-so-sneaky-and-hidden temp file.  I figured it's
> a deep dark secret, since it was gone when the update finished.  :-)

Egads! I've been found out!

:-)

> Seriously, though, we should figure out what to do about this.  The
> user shouldn't be seeing these files.

Have no fear... we don't really need that file, now that Joe has added some
new APIs to Neon. You may remember me talking about the whole push vs pull
in regards to the network and diffs and stuff. With the new Neon APIs and
flipping around apply_txdelta (change #6), then we can skip the temp file.


Oh... that's for an update. Hmm. (I was thinking "commit")

Okay... that file is for the "report" that we send to the server. I think
there was going to be an API for writing bits, rather than the whole thing.
I don't remember and will need to look at the Neon API again. I also had
some changes in mind for Neon that I volunteered for a couple months ago(!)
but Joe may have already done them. Anyway... I believe we may be able to
toss the file. If not, we may want to look at using SVN/tmp/ to hold it.

Cheers,
-g

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org