You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Garret Wilson <ga...@globalmentor.com> on 2003/12/29 17:19:05 UTC
.autogen.sh error for svn revision 8113
I did a svn up to revision 8113 and then ran ./autogen.sh (the same as
I've done for previous revisions). I get:
buildcheck: checking installation...
buildcheck: autoconf version 2.57 (ok)
buildcheck: autoheader version 2.57 (ok)
buildcheck: libtool version 1.4.3 (ok)
buildcheck: neon version 0.24.4 (ok)
Copying libtool helper: /usr/share/aclocal/libtool.m4
Creating getdate.c...
subversion/libsvn_subr/getdate.y contains 10 shift/reduce conflicts.
Creating build-outputs.mk...
File "./gen-make.py", line 159
print >> opt_conf, "[options]"
^
SyntaxError: invalid syntax
ERROR: gen-make.py failed
I've upgraded neon. I've upgraded Berkeley DB. I've upgraded Apache.
Perhaps I need to also upgrade Python, even though Python 1.5.2-27 has
worked fine for me for all earlier svn revisions.
So I downloaded Python 2.3.3, ran configure, and then make:
gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o
Modules/python.c
In file included from Include/Python.h:48,
from Modules/python.c:3:
Include/pyport.h:554:2: #error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc config?)."
make: *** [Modules/python.o] Error 1
Grrr...
Before I go further---is my original problem really because of my early
Python version?
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: in-tree Berkeley DB
Posted by Garret Wilson <ga...@globalmentor.com>.
Sander Striker wrote:
> On Tue, 2003-12-30 at 19:45, Garret Wilson wrote:
>>In fact, during my tribulations yesterday, I downloaded the 0.35.1
>>tarball. During ./configure, it notified me that Berkeley DB was not
>>included, but if I wanted it included I should copy it to a db/
>>directory in the tree. As in-tree Berkeley DB is no longer supported,
>>these instruction messages should probably be changed.
>
> I've checked to see if those instructions were still there and to my
> knowledge there are none. If you are sure there are, please point
> them out so they can be removed.
Ahh, you're right. In my spiral to insanity yesterday, I compiled about
five different tarball versions. One of them *did* tell me to use db/,
but after checking I realize that it was not 0.35.1. It was likely a
tarball of a version before in-tree Berkeley-DB was banned.
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: in-tree Berkeley DB
Posted by Sander Striker <st...@apache.org>.
On Tue, 2003-12-30 at 19:45, Garret Wilson wrote:
> Sander Striker wrote:
> > On Mon, 2003-12-29 at 19:14, Garret Wilson wrote:
> >>configure: error: Configuring against an in-tree copy of Berkeley DB is no
> >> longer supported. Berkeley DB must be separately
> >>installed,
> >> and perhaps specified by adding --with-berkeley-db=PATH
> >
> >
> > Hmmm. There is no db/ directory in your source tree?
> >
> >>I've never used an in-tree copy of Berkeley DB, as far as I know...
>
> You know, now that I think about it, I think that *I'm* the one who
> added the db/ directory---probably following the instructions of the
> bootstrap tarball I originally started with months ago.
>
> In fact, during my tribulations yesterday, I downloaded the 0.35.1
> tarball. During ./configure, it notified me that Berkeley DB was not
> included, but if I wanted it included I should copy it to a db/
> directory in the tree. As in-tree Berkeley DB is no longer supported,
> these instruction messages should probably be changed.
I've checked to see if those instructions were still there and to my
knowledge there are none. If you are sure there are, please point
them out so they can be removed.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: in-tree Berkeley DB
Posted by Garret Wilson <ga...@globalmentor.com>.
Sander Striker wrote:
> On Mon, 2003-12-29 at 19:14, Garret Wilson wrote:
>>configure: error: Configuring against an in-tree copy of Berkeley DB is no
>> longer supported. Berkeley DB must be separately
>>installed,
>> and perhaps specified by adding --with-berkeley-db=PATH
>
>
> Hmmm. There is no db/ directory in your source tree?
>
>>I've never used an in-tree copy of Berkeley DB, as far as I know...
You know, now that I think about it, I think that *I'm* the one who
added the db/ directory---probably following the instructions of the
bootstrap tarball I originally started with months ago.
In fact, during my tribulations yesterday, I downloaded the 0.35.1
tarball. During ./configure, it notified me that Berkeley DB was not
included, but if I wanted it included I should copy it to a db/
directory in the tree. As in-tree Berkeley DB is no longer supported,
these instruction messages should probably be changed.
Cheers,
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: in-tree Berkeley DB (was: Re: .autogen.sh error for svn
revision 8113)
Posted by Sander Striker <st...@apache.org>.
On Mon, 2003-12-29 at 19:14, Garret Wilson wrote:
> However, when trying to configure Subversion:
>
> ./configure --with-libs=/usr/local/ssl --with-ssl
> --with-apr=/usr/local/apache2 --with-apr-util=/usr/local/apache2
> --with-berkeley-db=/usr/local/BerkeleyDB.4.2
>
> I now get:
>
> [...]
> configure: Apache Portable Runtime (APR) library configuration
> checking for APR... yes
> checking APR version... 0.9.5
> configure: Apache Portable Runtime Utility (APRUTIL) library configuration
> checking for APR-util... yes
> checking APR-UTIL version... 0.9.5
> configure: error: Configuring against an in-tree copy of Berkeley DB is no
> longer supported. Berkeley DB must be separately
> installed,
> and perhaps specified by adding --with-berkeley-db=PATH
Hmmm. There is no db/ directory in your source tree?
> I've never used an in-tree copy of Berkeley DB, as far as I know, and as
> you can see I *am* using the --with-berkeley-db switch.
Ah, yes, and you shouldn't. You should only use this switch when
apr-util is in-tree. Maybe this isn't clear from the docs.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error 139 and svn core dump
Posted by mark benedetto king <mb...@lowlatency.com>.
On Mon, Dec 29, 2003 at 02:49:15PM -0800, Garret Wilson wrote:
> ...and even worse it gets. See below.
>
> Ben Collins-Sussman wrote:
> >On Mon, 2003-12-29 at 15:28, Garret Wilson wrote:
> >
> >>This gets even worse:
> >>
> >>I downloaded a brand new 0.35.1 tarball, and ran make (but not make
> >>install). There were no errors. subversion/clients/cmdline/svn then gives:
> >>
> >>Segmentation fault (core dumped)
> >
> >It sounds like you either have libc problems, or that (somehow) your svn
> >binary linked against older libsvn_* libraries in your system. Is that
> >possible? Look at 'ldd' output. Purge your system of old libraries.
>
> I removed all the svn libraries, and then made a client-only svn from
> the 0.32.1 tarball. Same core dump. Now I *know* something is horribly
> wrong, because 0.32.1 is the version I was running nicely before this
> whole ordeal started.
Just wondering: where did you get your APR from? When I upgraded APR
recently, I started getting bizarre coredumps until I did a complete
rebuild of APR.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error 139 and svn core dump
Posted by Garret Wilson <ga...@globalmentor.com>.
...and even worse it gets. See below.
Ben Collins-Sussman wrote:
> On Mon, 2003-12-29 at 15:28, Garret Wilson wrote:
>
>>This gets even worse:
>>
>>I downloaded a brand new 0.35.1 tarball, and ran make (but not make
>>install). There were no errors. subversion/clients/cmdline/svn then gives:
>>
>>Segmentation fault (core dumped)
>
> It sounds like you either have libc problems, or that (somehow) your svn
> binary linked against older libsvn_* libraries in your system. Is that
> possible? Look at 'ldd' output. Purge your system of old libraries.
I removed all the svn libraries, and then made a client-only svn from
the 0.32.1 tarball. Same core dump. Now I *know* something is horribly
wrong, because 0.32.1 is the version I was running nicely before this
whole ordeal started.
With a client-only 0.32.1, the new Berkeley DB shouldn't be an issue. As
this is straight from the tarball, the new neon shouldn't be an issue,
either. That leaves only two things that I've changed: Python and gcc.
The latest subversion wouldn't build with the pre-2.0 Python I had been
using on all the other revisions, so I had to upgrade. Problem is, Red
Hat 7.0 has a gcc bug that won't let Python 2.0 build, so I had to
upgrade gcc.
I originally had some old glibc RPM that came with Red Hat 7.0---maybe
2.1.9x. At some point before today, I had downloaded, built, and
installed glibc 2.3.2 from source. This apparently didn't change the gcc
header file needed by Python to correctly compile (see LONG_BIT
definition issue at
http://www.python.org/cgi-bin/moinmoin/Python20FrequentlyAskedQuestions ).
I therefore upgraded Red Hat glibc by using:
rpm -Uvh glibc-2.2.4-18.7.0.9.i686.rpm
glibc-common-2.2.4-18.7.0.9.i386.rpm glibc-devel-2.2.4-18.7.0.9.i386.rpm
This upgrade seemed to go fine. I don't know what this did to the
glibc-2.3.2 I had installed from the source, however.
Everything builds fine, with no errors. I still get core dumps. Any,
*any* help will be extremely appreciated.
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error 139 and svn core dump (solved)
Posted by Garret Wilson <ga...@globalmentor.com>.
Ben Collins-Sussman wrote:
> It sounds like you either have libc problems, or that (somehow) your svn
> binary linked against older libsvn_* libraries in your system. Is that
> possible? Look at 'ldd' output. Purge your system of old libraries.
Thank you, everyone, for your input on my seemingly endless stream of
problems. I never want to go through this again.
After I tried to recompile and reinstall glibc (which I had successfully
done before), I was told I couldn't because I had an old gcc. Yep, my
gcc was 2.96. I downloaded, compiled, and installed gcc 3.3.2, and svn
worked! I'm now happily running 0.35.1 on client and server.
Questions still linger in my mind:
* What's the relationship between gcc and glibc?
* Why did gcc work before for the other svn versions?
* Why does
http://www.python.org/cgi-bin/moinmoin/Python20FrequentlyAskedQuestions
seem to indicate that gcc will be updated by updating glibc?
* Why did my updating glibc, which fixed the problem for compiling
Python 2 on Red Hat 7, cause problems with gcc?
I can only assume that updating glibc via RPM to fix the Python problem
somehow *reverted* my gcc to an old version that was buggy and created a
buggy svn. (I don't know why Python compiled correctly, though. I guess
I should go back and recompile it just in case.)
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error 139 and svn core dump
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mon, 2003-12-29 at 15:28, Garret Wilson wrote:
> This gets even worse:
>
> I downloaded a brand new 0.35.1 tarball, and ran make (but not make
> install). There were no errors. subversion/clients/cmdline/svn then gives:
>
> Segmentation fault (core dumped)
It sounds like you either have libc problems, or that (somehow) your svn
binary linked against older libsvn_* libraries in your system. Is that
possible? Look at 'ldd' output. Purge your system of old libraries.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error 139 and svn core dump
Posted by Garret Wilson <ga...@globalmentor.com>.
This gets even worse:
I downloaded a brand new 0.35.1 tarball, and ran make (but not make
install). There were no errors. subversion/clients/cmdline/svn then gives:
Segmentation fault (core dumped)
Where can I go from here? Basically, my entire svn configuration is
hosed. I guess I'll have to downgrade tarball versions until I can find
something that works.
I'm running Red Hat 7.0.
Garret
P.S. Note that I a lot of the following warning:
libtool: link: warning: library `/usr/lib/libgdbm.la' was moved.
I have no idea what causes this, but I have always received this warning
on previous revisions, and svn would run just fine.
Garret Wilson wrote:
> Garret Wilson wrote:
>
>> chmod 755 /usr/local/apache2/modules/mod_authz_svn.so
>> [activating module `authz_svn' in /usr/local/apache2/conf/httpd.conf]
>> subversion/svnversion/svnversion . /repos/svn/trunk >
>> /usr/local/include/subversion-1/svn-revision.txt
>> make: *** [revision-install] Error 139
>
>
> Well, first of all, I don't have a /repos/svn/trunk on my system. How do
> I get one---better yet, why do I need one?
>
> Trying to run svn now give me:
>
> Segmentation fault (core dumped)
>
> That's not good.
>
> Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error 139 and svn core dump
Posted by Garret Wilson <ga...@globalmentor.com>.
Garret Wilson wrote:
> chmod 755 /usr/local/apache2/modules/mod_authz_svn.so
> [activating module `authz_svn' in /usr/local/apache2/conf/httpd.conf]
> subversion/svnversion/svnversion . /repos/svn/trunk >
> /usr/local/include/subversion-1/svn-revision.txt
> make: *** [revision-install] Error 139
Well, first of all, I don't have a /repos/svn/trunk on my system. How do
I get one---better yet, why do I need one?
Trying to run svn now give me:
Segmentation fault (core dumped)
That's not good.
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Error 139 (was: in-tree Berkeley DB)
Posted by Garret Wilson <ga...@globalmentor.com>.
Just when I thought I was going to make it...
During make install, everything seems to go OK except for the last line:
chmod 755 /usr/local/apache2/modules/mod_authz_svn.so
[activating module `authz_svn' in /usr/local/apache2/conf/httpd.conf]
subversion/svnversion/svnversion . /repos/svn/trunk >
/usr/local/include/subversion-1/svn-revision.txt
make: *** [revision-install] Error 139
What does that mean? Was installation successful or no?
Garret
Garret Wilson wrote:
> Garret Wilson wrote:
>
>> I've never used an in-tree copy of Berkeley DB, as far as I know, and
>> as you can see I *am* using the --with-berkeley-db switch.
>
>
> There *was*, however, a db directory that apparently hadn't been
> modified in almost a year. Once I removed that, configuration proceeded.
>
> Is it possible that the original bootstrap tarball contained an in-tree
> Berkeley DB? If so, I suppose the new bootstrap tarballs do not, as they
> would never build...
>
> Subversion is compiling, now. My fingers are crossed.
>
> Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: in-tree Berkeley DB
Posted by Garret Wilson <ga...@globalmentor.com>.
Garret Wilson wrote:
> I've never used an in-tree copy of Berkeley DB, as far as I know, and as
> you can see I *am* using the --with-berkeley-db switch.
There *was*, however, a db directory that apparently hadn't been
modified in almost a year. Once I removed that, configuration proceeded.
Is it possible that the original bootstrap tarball contained an in-tree
Berkeley DB? If so, I suppose the new bootstrap tarballs do not, as they
would never build...
Subversion is compiling, now. My fingers are crossed.
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
in-tree Berkeley DB (was: Re: .autogen.sh error for svn revision
8113)
Posted by Garret Wilson <ga...@globalmentor.com>.
I'm beginning to remember why I despise Red Hat and RPMs.
It turns out Red Het 7.0 has a gcc bug. (See
http://www.python.org/cgi-bin/moinmoin/Python20FrequentlyAskedQuestions
and http://rhn.redhat.com/errata/RHBA-2000-079.html ). I finally found
appropriate RPMs, but because of dependencies, I had to install glibc,
glibc-common, and glibc-devel. (I have no idea what this did to my glibc
I had already installed from the source.)
Python 2 then compiled. Subversion autogen.sh then worked correctly.
However, when trying to configure Subversion:
./configure --with-libs=/usr/local/ssl --with-ssl
--with-apr=/usr/local/apache2 --with-apr-util=/usr/local/apache2
--with-berkeley-db=/usr/local/BerkeleyDB.4.2
I now get:
[...]
configure: Apache Portable Runtime (APR) library configuration
checking for APR... yes
checking APR version... 0.9.5
configure: Apache Portable Runtime Utility (APRUTIL) library configuration
checking for APR-util... yes
checking APR-UTIL version... 0.9.5
configure: error: Configuring against an in-tree copy of Berkeley DB is no
longer supported. Berkeley DB must be separately
installed,
and perhaps specified by adding --with-berkeley-db=PATH
I've never used an in-tree copy of Berkeley DB, as far as I know, and as
you can see I *am* using the --with-berkeley-db switch.
I never new upgrading could be so difficult...
Garret
Garret Wilson wrote:
> I did a svn up to revision 8113 and then ran ./autogen.sh (the same as
> I've done for previous revisions). I get:
>
> buildcheck: checking installation...
> buildcheck: autoconf version 2.57 (ok)
> buildcheck: autoheader version 2.57 (ok)
> buildcheck: libtool version 1.4.3 (ok)
> buildcheck: neon version 0.24.4 (ok)
> Copying libtool helper: /usr/share/aclocal/libtool.m4
> Creating getdate.c...
> subversion/libsvn_subr/getdate.y contains 10 shift/reduce conflicts.
> Creating build-outputs.mk...
> File "./gen-make.py", line 159
> print >> opt_conf, "[options]"
> ^
> SyntaxError: invalid syntax
> ERROR: gen-make.py failed
>
> I've upgraded neon. I've upgraded Berkeley DB. I've upgraded Apache.
> Perhaps I need to also upgrade Python, even though Python 1.5.2-27 has
> worked fine for me for all earlier svn revisions.
>
> So I downloaded Python 2.3.3, ran configure, and then make:
>
> gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
> -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o
> Modules/python.c
> In file included from Include/Python.h:48,
> from Modules/python.c:3:
> Include/pyport.h:554:2: #error "LONG_BIT definition appears wrong for
> platform (bad gcc/glibc config?)."
> make: *** [Modules/python.o] Error 1
>
> Grrr...
>
> Before I go further---is my original problem really because of my early
> Python version?
>
> Garret
>
>
>
> ---------------------------------------------------------------------
> 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