[Date Prev][Date Next]
Re: Help on Digital Unix 4.0 with BerkeleyDB 2.7.5
> At 12:32 PM 7/13/99 -0400, Ronald E. Fortin wrote:
> >Has anyone had any luck in building OpenLDAP 1.2.3 using BerkeleyDB 2.7.5?
> >I build BerkeleyDB and installed it in the default location and then set the CPPFLAGS and LDFLAGS appropriately. However, the
> >./configure program does not seem to find the db_open function in the library so it doesn't think that it is db2.
> >Any words of wisdom?
> I would guess that you are getting a different "-ldb" than you expect
> or that -ldb for some reason doesn't have db_open. You might use
> nm or something to check.
> You can force the test to be true using:
> env ac_cv_lib_db_db_open=yes ./configure
I just built this very same system. I actually had two problems. One
was that config.sub did not recognize my version of alpha (config.guess
returns alphaev6-dec-osf4.0e for us). Patch for this is:
RCS file: /repo/OpenLDAP/pkg/ldap/build/config.sub,v
retrieving revision 188.8.131.52
diff -r184.108.40.206 config.sub
< | alpha | alphaev5 | alphaev56 | we32k | ns16k | clipper \
> | alpha | alphaev5 | alphaev56 | alphaev6 | we32k | ns16k | clipper \
< | alpha-* | alphaev5-* | alphaev56-* | we32k-* | cydra-* \
> | alpha-* | alphaev5-* | alphaev56-* | alphaev6-* | we32k-* | cydra-* \
Or you can get the latest config.guess and config.sub from the autoconf
package from gnu. I stop short of committing them. I mostly work with
the OPENLDAP_REL_ENG_1_2 release, and the new versions may well be commited
already to head development tree, since BeOS is mentioned a lot in the
new stuff and I know there are a lot of BeOS fans using this project.
Then, there's a very annoying problem that apparently the OSF won't
search for static libraries by default (or something). Anyways, after
a lot of hacking and hair pulling, I went in and extracted the objects
from libdb.a and built them into a shared library (I believe all code
on an alpha is position-independent).
Then configure found db_open just fine. I think there's probably a C compiler
option, like "search for libraries in the old style" that would also have
worked around this, but I lean towards a preference to shared libraries
anyways. Then I had to manually go into the slapd server
and tools directories and added a "-rpath path-to-directory-containing-db"
(which you wouldn't have to do if you stuck with the static libraries).
By the way, once I got it built, all the tests worked fine, so you're
heading in a good direction.