[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: configure: error: Berkeley DB version mismatch
- To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Subject: RE: configure: error: Berkeley DB version mismatch
- From: "Tay, Gary" <Gary_Tay@platts.com>
- Date: Wed, 15 Sep 2004 14:30:23 +0800
- Cc: <cam@yak.com.au>, "OpenLDAP Software List" <openldap-software@OpenLDAP.org>
- Content-class: urn:content-classes:message
- Thread-index: AcSa6Aqq1iTvI9VmRbG8M5VbTe5hcwAA4oTg
- Thread-topic: configure: error: Berkeley DB version mismatch
I'm not a developer, what I said are from my "install/configure"
experiences and may not merit anything.
The source dist files come with an original Makefile. I am referring to
doing "make distclean; make clean" while this Makefile exists, then
"./configure" again.
>From my experience, make distclean and make clean do a clean-up of some
header files depending on the context, and that may help subsequent
actions and troubleshooting.
When I dealed with "./configure" issues related to NSS_LDAP and
PAM_LDAP, I frequently issued this command to "start from fresh" and I
usually get it right with "./configure". One good example here is the
"ldap.h" header file which gave me trouble while "./confguring"s.
I looked what "make distclean" is doing:
distclean: veryclean FORCE
veryclean: veryclean-common veryclean-local FORCE
veryclean-common: clean-common FORCE
veryclean-local: FORCE
$(RM) config.cache config.status libtool stamp-h stamp-h.in
clean-common: FORCE
@echo "Making clean in `$(PWD)`"
@for i in $(SUBDIRS) $(CLEANDIRS); do \
echo " Entering subdirectory $$i"; \
( cd $$i; $(MAKE) $(MFLAGS) clean ); \
if test $$? != 0 ; then exit 1; fi ; \
echo " ";
\
done
-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Wednesday, September 15, 2004 1:52 PM
To: Tay, Gary
Cc: cam@yak.com.au; OpenLDAP Software List
Subject: RE: configure: error: Berkeley DB version mismatch
At 09:46 PM 9/14/2004, Tay, Gary wrote:
>It is good practice running "make distclean; make clean" b4 re-running
>"configure", this clears some cache info (config.cache?)
This doesn't apply to OpenLDAP Software. (And since
configure is failing, there aren't yet Makefiles for
make anyways.)
>Pls try to see if it makes any difference.
>
>Rgds
>Gary
>
>-----Original Message-----
>From: owner-openldap-software@OpenLDAP.org
>[mailto:owner-openldap-software@OpenLDAP.org] On Behalf Of Cameron
>Gregg
>Sent: Wednesday, September 15, 2004 12:26 PM
>To: OpenLDAP Software List
>Subject: Re: configure: error: Berkeley DB version mismatch
>
>
>Quanah Gibson-Mount wrote:
>
>>
>>
>> --On Wednesday, September 15, 2004 11:10 AM +1000 Cameron Gregg
>> <cam@yak.com.au> wrote:
>>
>>> On solaris it only gives me the first two lines below, on linux
>>> (slackware 10), it gives me the following lines:
>>>
>>>
>>> checking for Berkeley DB link (-ldb-4.2)... yes
>>> checking for Berkeley DB version match... Berkeley DB version
>mismatch
>>> expected: Sleepycat Software: Berkeley DB 3.3.11: (July 12,
>>> 2001)
>>> got: Sleepycat Software: Berkeley DB 4.2.52: (December 3,
>2003)
>>> no
>>> configure: error: Berkeley DB version mismatch
>>>
>>>
>>> Why is the latest openldap looking for a version of Berkeley db that
>>> is 3 years old?
>>
>>
>> If I recall correctly, this generally indicates that it found older
>> OpenLDAP libraries around that use BDB 3.3. You need to adjust your
>> environment variables for where to look for libraries.
>>
>> You may (or may not) find
>>
>> <http://www.stanford.edu/services/directory/openldap>
>>
>> useful.
>>
>
>Thanks. I've figured the linux problem, you are right, it pointed to an
>old db.h
>
>on slackware 10 , /usr/include/db.h symlinks to /usr/include/db3/db.h .
>there is also a /usr/include/db4/db.h , so I just changed the symlink
>and all worked fine.
>
>
>I still cant work out the solaris prob..
>
>Thanks!
>CAmeron