MIME-Version: 1.0
In-Reply-To: <rt-7572-38182.3.77204554482546@krbdev.mit.edu>
References: <rt-7572@krbdev.mit.edu> <rt-7572-38182.3.77204554482546@krbdev.mit.edu>
From: Mark Ashley <mark@ibiblio.org>
Date: Thu, 21 Feb 2013 14:51:55 +1100
Message-ID: <CADmdEskfyPY74d=oBL9jED6f7-tNv8+eKquYHeVx+t-3j7Eovw@mail.gmail.com>
Subject: Re: [krbdev.mit.edu #7572] krb5 1.11 doesn't build on Solaris w/ Sun Studio, the first time. A re-make works
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
Content-Type: text/plain; charset=ISO-8859-1
RT-Send-Cc: 
Content-Length: 3707

Hey Greg,

Thanks for the follow up. It appears that Oracle has deprecated
BTREEINFO in its latest BDB versions.

Digging into the krb5 install guide:

--with-system-db
Use an installed version of the Berkeley DB package, which must
provide an API compatible with version 1.85. This option is
unsupported and untested. In particular, we do not know if the
database-rename code used in the dumpfile load operation will behave
properly. If this option is not given, a version supplied with the
Kerberos sources will be built and installed. (We are not updating
this version at this time because of licensing issues with newer
versions that we haven't investigated sufficiently yet.)

So it looks like the configure script could be enhanced to first hunt
for <db_185.h> when --with-system-db is used.

These perl replacement lines result in a full clean compile with what
I assume is the expected results.

    cd /var/tmp
    rm -rf krb5-1.11
    untgz /usr/local/src/crypto/krb5-1.11.tar.gz
    cd krb5-1.11/src
    ./configure --prefix=/usr/local \
        --with-ldap \
        --with-system-db \
        --with-tcl=/usr/local \
        --with-pkinit-crypto-impl=openssl \
        --with-readline
    /bin/perl -pe 's%<db.h>%<db_185.h>%' -i ./plugins/kdb/db2/policy_db.h
    /bin/perl -pe 's%<db.h>%<db_185.h>%' -i ./plugins/kdb/db2/adb_openclose.c
    /bin/perl -pe 's%<db.h>%<db_185.h>%' -i ./plugins/kdb/db2/kdb_db2.c
    /bin/perl -pe 's%<db.h>%<db_185.h>%' -i ./plugins/kdb/db2/db2_exp.c
    /bin/perl -pe 's%<db.h>%<db_185.h>%' -i ./plugins/kdb/hdb/kdb_hdb.c
    /bin/perl -pe 's%<db.h>%<db_185.h>%' -i ./plugins/kdb/hdb/kdb_marshal.c
    /bin/perl -pe 's%<db.h>%<db_185.h>%' -i ./plugins/kdb/hdb/kdb_windc.c
    /bin/perl -pe 's%<db.h>%<db_185.h>%' -i ./kadmin/testing/util/bsddb_dump.c
    /bin/perl -pe 's%<db.h>%<db_185.h>%' -i ./include/Makefile
    gmake
    gmake install

ta,
Mark.

My /usr/local/include/db.h:
#define DB_VERSION_STRING       "Berkeley DB 4.8.30: (April  9, 2010)"

# grep BTREE /usr/local/include/*
/usr/local/include/db.h:struct __db_bt_stat;    typedef struct
__db_bt_stat DB_BTREE_STAT;
/usr/local/include/db.h:        DB_BTREE=1,
/usr/local/include/db.h:#define DB_BTREEVERSION 9               /*
Current btree version. */
/usr/local/include/db.h:#define DB_BTREEOLDVER  8               /*
Oldest btree version supported. */
/usr/local/include/db.h:#define DB_BTREEMAGIC   0x053162
/usr/local/include/db.h:#define DB_OK_BTREE     0x01
/usr/local/include/db_185.h:#define     R_LAST          6
 /* seq (BTREE, RECNO) */
/usr/local/include/db_185.h:#define     R_PREV          9
 /* seq (BTREE, RECNO) */
/usr/local/include/db_185.h:typedef enum { DB_BTREE, DB_HASH, DB_RECNO } DBTYPE;
/usr/local/include/db_185.h:#define     BTREEMAGIC      0x053162
/usr/local/include/db_185.h:#define     BTREEVERSION    3
/usr/local/include/db_185.h:} BTREEINFO;
/usr/local/include/kdb.h:#define KRB5_KDB_CREATE_BTREE           0x00000001
/usr/local/include/ldap.h:#define LDAP_URLEXT_X_SEARCHEDSUBTREEOID \
/usr/local/include/ldap.h:#define LDAP_URLEXT_X_SEARCHEDSUBTREE
"x-searchedSubtree"
/usr/local/include/ldap.h:#define LDAP_SCOPE_SUBTREE
((ber_int_t) 0x0002)
/usr/local/include/ldap.h:#define LDAP_SCOPE_SUB
 LDAP_SCOPE_SUBTREE


On Wed, Feb 20, 2013 at 5:06 PM, Greg Hudson via RT
<rt-comment@krbdev.mit.edu> wrote:
> Your build was configured with --with-system-db, so plugins/kdb/db2/libdb2
> was not built, and <db.h> was taken from /usr/local/include or the system
> include path.  If that system header does not defined BTREEINFO or
> HASHINFO, then the failure you observed is unsurprising.  Those symbols
> are a documented part of the BDB interface at least as of 4.2.