Bug 70935

Summary:	BerkelyDB setup fails in configure script
Product:	[Applications] kdevelop	Reporter:	Michael Satterwhite <satterwh>
Component:	general	Assignee:	KDevelop Developers <kdevelop-devel>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	NOR
Version:	3.0.0b2
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Michael Satterwhite 2003-12-20 21:45:41 UTC

Version:           3.0.0 Beta 2 (using KDE KDE 3.1.1)
Installed from:    SuSE RPMs
OS:          Linux

Although a similar problem was reported and marked resolved, this problem has been recurring in the forum. When trying to do ./configure with KDevelop 3 Beta 2, configure will fail if the BerkelyDB is in any non-standard location - and an fresh install of the BerkelyDB from their site will put it in an non-standard location. This occurs even if the location is specified with --with-extra-includes and --with-extra-libs.

The problem is that by the time the check for the BerkelyDB is done, the CXXFLAGS variable has no references to the include or library directories (for verification, dump this variable at line 36070 in the configure script). Without this reference, it will not be able to find the BerkelyDB - even though it is correctly on the system.

A workaround for this problem is to apply the following patch:

36068a36069,36074
> #The KDevelop configure script does not take into account
> #the --with-extra-includes or --with-extra-libs flag. This
> #may cause the check for software to fail. To chech for
> #the Berkely DB, add these flags back in now
>
> CXXFLAGS="$CXXFLAGS $all_includes $all_libraries"

Note that I have not checked for any other required components that may be affected by the loss of the include / library references, which is why I consider it a workaround rather than a fix. It does, however, correct the problem with the BerkelyDB.

Comment 1 Arjan van Leeuwen 2003-12-22 23:12:36 UTC

This is also a problem on FreeBSD, where the bdb headers reside in /usr/local/include/dbX (where X is the version of bdb, e.g. 2, 3, or 41) and the libraries are in /usr/local/lib and have a name that includes the version number too (e.g. libdb41.so and libdb3.so). 

The problem with the headers can be fixed with this workaround, the problem with the libraries can't. There seem to be other checks in the configure for the bdb libraries from Python, and they do the checks right. Maybe those can be used?

Comment 2 Michael Satterwhite 2003-12-23 00:25:34 UTC

Actually - at least in Linux - the workaround above DOES correct the problem with the libraries. If the $all_libraries variable is omitted in the fix above, the configure fails just as it does if the $all_includes is omitted.

Comment 3 Arjan van Leeuwen 2003-12-28 21:29:47 UTC

Yes, that's correct. The problem is not that the library directory is not included, but that the library has a different name in FreeBSD (e.g. it has to use -ldb41, -ldb4 or -ldb3 instead of -ldb, depending on the version). 

To compile KDevelop on my FreeBSD machine, I now just replace -ldb with -ldb41 in kdevelop.m4.in and lib/catalog/Makefile.am, in addition to the fix you propose.

Comment 4 Amilcar do Carmo Lucas 2004-06-17 00:34:17 UTC

snip from the website:

Here is an example of a configure for systems that may have more than one db.h or whose libdb is called something else (like libdb3) a typical example of such systems is FreeBSD:
 

$ ./configure --prefix=$KDEDIR --with-db-libdir=/usr/local/lib --with-db-includedir=/usr/local/include --with-db-lib=db3

So I think this one is fixed in KDevelop HEAD.

Comment 5 Amilcar do Carmo Lucas 2004-06-25 21:02:30 UTC

adymo fix it on HEAD in yet another "more powerfull way" (tm)
KDevelop HEAD includes it's own copy of BerkleyDB.