[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

maddening tarball problems.

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-10-30 05:18:52 CET

OK, so I've rolled a 0.14.5 tarball, sitting right here:

 http://newton.ch.collab.net/pub/subversion-r3566.tar.gz

The main point of this release is to fix the berkeley db detection,
which was broken in 0.14.4.

But despite the fact that it works:

  * on FreeBSD, with no ./configure args
  * for Brane and Philip, who explicitly pass --with-berkeley-db=

... this tarball is *still* not working for Fitz on Debian, or for Ed
Marshall on Redhat 8.

For Fitz on Debian (no configure args), he sees:

checking for Berkeley DB in /usr/local/include/db4 and /usr/local/lib
(as db4)... no
checking for Berkeley DB in /usr/local/include/db4 and /usr/local/lib
(as db)... no

...and that's it, its just gives up, never finds berkeley db. It
never even tries to look in /usr/local/BerkeleyDB.4.0, where it is.

For Ed on Redhat 8 (no configure args), he sees a false positive:

checking for Berkeley DB in /usr/local/include/db4 and /usr/local/lib (as db)... yes

... it then tacks on the oddball paths and builds anyway, even though
it's in /lib/libdb-4.0.so and /usr/include/db4.

I'm wondering if these problems are due to this change I made in our
m4 file:

      places="/usr/local/include/db4:/usr/local/lib std /usr/local
              /usr/local/BerkeleyDB.$1.$2 /usr/include/db4:/usr/lib"

The 'std' thing used to be first on the list, which was a change
someone else made a while back. (It contradicts the comment.) If you
look further down the logic, it seems to be *depending* on that fact
that 'std' comes first, maybe? That is, if 'std' isn't the first
place to be tested, then perhaps LIBS and CPPFLAGS can end up
accidentally working on the oddball path, simply because it finds DB
in the standard places anyway? That would explain Ed's situation.

I have no explanation for Fitz's situation....?

Can someone (brane? philip?) look at this problem?

I don't think the answer is to simply put 'std' first in the list
again, but rather to fix the logic further down. If 'std' is first in
the list, then everything breaks on FreeBSD. As the comment says, we
end up finding /usr/include/db.h, which is db2, and pairing it with
/usr/local/lib/libdb.so, which is newer.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 30 05:19:02 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.