Ticket History #3838: static-only builds no longer possible

Yep, static builds are definitely low priority at the moment. Adding
DL_LIB is a start, but the db2 code still won't build properly; some
confusion between our configure scripts and makefiles for the
different kinds of target objects that can be built....

Ken

From krb5-bugs-incoming-bounces@PCH.mit.edu Fri Aug 4 23:33:57 2006
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by krbdev.mit.edu (8.9.3p2) with ESMTP
id XAA21661; Fri, 4 Aug 2006 23:33:57 -0400 (EDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1])
by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k753XHU4012719
for <krb5-send-pr@krbdev.mit.edu>; Fri, 4 Aug 2006 23:33:17 -0400
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
[18.7.7.76])
by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k74D4orl013765
for <krb5-bugs-incoming@PCH.mit.edu>; Fri, 4 Aug 2006 09:04:50 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
k74D4rBl018429
for <krb5-bugs@mit.edu>; Fri, 4 Aug 2006 09:04:53 -0400 (EDT)
Received: from coppi.bath.ac.uk (coppi.bath.ac.uk [138.38.32.23])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mit.edu (Spam Firewall) with ESMTP id A54663AB60
for <krb5-bugs@mit.edu>; Fri, 4 Aug 2006 09:04:30 -0400 (EDT)
Received: from mary.bath.ac.uk ([138.38.32.14] ident=mmdf)
by coppi.bath.ac.uk with smtp id 1G8zLn-0007H2-FW
for krb5-bugs@mit.edu
(return-path <D.H.Davis@bath.ac.uk>); Fri, 04 Aug 2006 14:04:28 +0100
Received: from hinault.bath.ac.uk
( [oM937cuI2+aa3fSHE1XjgT+OHQbg4X3X]@hinault.bath.ac.uk [138.38.52.28]
) by bath.ac.uk id aa29533 ; 4 Aug 2006 14:04 +0100
Received: from ccsdhd by hinault.bath.ac.uk with local id 1G8zLm-0005Ns-BQ;
Fri, 04 Aug 2006 14:04:26 +0100
To: krb5-bugs@mit.edu
Subject: Problems building krb5-1.5 with static libraries on OpenBSD3.9.
From: Dennis Davis <D.H.Davis@bath.ac.uk>
X-send-pr-version: 3.99
Message-Id: <E1G8zLm-0005Ns-BQ@hinault.bath.ac.uk>
Date: Fri, 04 Aug 2006 14:04:26 +0100
X-Scanner: 67bb9ca424d3cccf619cc9d32429bbc2639dd8f8
X-Spam-Score: 0.12
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Fri, 04 Aug 2006 23:33:14 -0400
Cc: Dennis Davis <d.h.davis@bath.ac.uk>
X-BeenThere: krb5-bugs-incoming@mailman.mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: Dennis Davis <D.H.Davis@bath.ac.uk>
Sender: krb5-bugs-incoming-bounces@PCH.mit.edu
Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu


University of Bath, UK
merckx.bath.ac.uk [138.38.52.201],
running OpenBSD3.9
System: OpenBSD merckx.bath.ac.uk 3.9 EXIM_SERVER#0 i386


I can configure krb5-1.5-signed.tar on OpenBSD3.9 with a command
line of the form:

LDFLAGS=-lpthread \
CC=cc CFLAGS="-O2 -fPIC" \
./configure --prefix=/kerberosV \
--enable-dns-for-realm --without-krb4 \
--with-tcl=/usr/local --enable-shared \
--disable-static --enable-thread-support

and the build works fine. I can tweak the code to cater for the
problem noted in:

http://krbdev.mit.edu/rt/Ticket/Display.html?id=3971

and it all seems to run OK.

Building with static and dynamic libraries requires:

LDFLAGS=-lpthread \
CC=cc CFLAGS="-O2 -fPIC" \
./configure --prefix=/kerberosV \
--enable-dns-for-realm --without-krb4 \
--with-tcl=/usr/local --enable-shared \
--enable-static --enable-thread-support

However the build fails with:

making all in plugins/kdb/db2/libdb2/test...
cp ./include/db.h ../../../../include/db.h
cp include/db-config.h ../../../../include/db-config.h
cp ./include/db-ndbm.h ../../../../include/db-ndbm.h
rm -f libdb.a
building static db library
set -x; objlist=`set -x && perl -p -e 'BEGIN { $SIG{__WARN__} = sub {die @_} }; $e=$ARGV; $e =~ s/OBJS\...$//; s/^/ /; s/ $//; s/ / $e/g;' hash/OBJS.ST btree/OBJS.ST db/OBJS.ST mpool/OBJS.ST recno/OBJS.ST clib/OBJS.ST` && ar cq libdb.a $objlist
+ set -x
+ perl -p -e BEGIN { $SIG{__WARN__} = sub {die @_} }; $e=$ARGV; $e =~ s/OBJS\...$//; s/^/ /; s/ $//; s/ / $e/g; hash/OBJS.ST btree/OBJS.ST db/OBJS.ST mpool/OBJS.ST recno/OBJS.ST clib/OBJS.ST
Can't open hash/OBJS.ST: No such file or directory.
+ objlist=
*** Error code 2

Stop in /tmp/krb5-1.5/src/plugins/kdb/db2/libdb2 (line 642 of Makefile).
*** Error code 1

Stop in /tmp/krb5-1.5/src/plugins/kdb/db2 (line 1053 of Makefile).
*** Error code 1

Stop in /tmp/krb5-1.5/src (line 1336 of Makefile).

and if I fix this I get a succession of similar failures.

Not applicable.
Run the following simple script after configuring as above and *before*
the main build.

#!/bin/sh

for i in \
./plugins/kdb/db2/libdb2/hash \
./plugins/kdb/db2/libdb2/db \
./plugins/kdb/db2/libdb2/mpool \
./plugins/kdb/db2/libdb2/btree \
./plugins/kdb/db2/libdb2/recno \
./plugins/kdb/db2/libdb2/clib
do
(cd $i; make OBJS.ST)
done

Yes: It was a pain to maintain the ability to compile libraries in
multiple modes, and deal with platforms like AIX where you don't
actually distinguish between them based on library suffix. Also,
we've added a plugin architecture that wants to be able to
dynamically load code that may depend on the Kerberos library or (for
internally built modules) internal libraries, and thus would need the
shared Kerberos library anyways. So now internal libraries that

These are not necessarily insurmountable problems, but most of the
approaches we've considered are either not trivial to implement or
raise issues that need some serious consideration (or both). For
example, statically linking in a bunch of "plugins" for the static
build means resolving name conflicts across all plugins we ship.
Some of the plugin interfaces currently work by providing one or more
dynamic object files in directory X that define symbol Y; that would
have to change, at least for the static mode. Removing dependencies
of dynamic plugins on the Kerberos libraries (that would no longer be
available dynamically) may be possible, by explicitly passing to the
plugin a structure holding function pointers for everything it could
possibly want, but it's ugly, and we don't have a good list of
symbols for that right now. (We have an export list used for
building shared libraries on Windows and Mac; it may or may not be
enough for plugins, but we know it's not enough to implement our own
KDC. We have another export list we use on UNIX, which is basically
everything including a bunch of private internal APIs you shouldn't
touch, and it will eventually get trimmed down; initially it was just
a placeholder so we could implement the *use* of the export list on
various UNIX platforms, and then worry about what the right export
list was later.)

You may be able to hack the configure scripts and Makefiles into
generating static libraries that can't load some plugins, and
building a KDC that won't work, etc., which may be enough for you.
We're probably not going to give you support for that kind of build
process though.

If you or someone else wants to dig into the issues around restoring
static builds -- I suspect the plugin handling is the biggest part of
it, but I'd also like to see a more general way of extending the
build process to multiple suffixes for object files, multiple
libraries, etc -- I'd be happy to try to give some feedback, but for
most of the "customer" base I think shared-only libraries work well
enough (based on feedback or at least lack of complaints, from end
users, system integrators, Kerberos Consortium members, etc), so it
hasn't been a priority for us to put effort into this currently,
relative to other projects in the works....

Ken