Provide a buildtool_roken make variable

When using roken in build tools, i.e., binaries which must be
executed during the build stage, the roken library must be usable
prior to the 'install' stage.  In particular, if the internal
rokenafs is used, the shared library will not be installed and
the runtime linker will not be able to find it, causing execution
of the build tool to fail.  To avoid this failure, librokenafs
must be linked statically into these build tools.

Unfortunately, the way we currently use libtool is not very
well aligned to libtools model of how it should be used.  As a result,
it does not seem feasible to cause libtool to link librokenafs
statically without breaking other parts of the build.

Libtool peeks at the compiler command-line arguments to affect its
behavior when invoked as a linker.  The flags -static, -all-static,
and -static-libtool-libs can affect whether dynamic or static linkage
is used for various libraries being linked into the executable.
Passing -all-static tells libtool to not do any dynamic linking at
all, but is silently a no-op if static linking is not possible (the
default situation on most modern Linuxen, OS X, and Solaris).
Passing -static causes libtool to not do any dynamic linking of
libtool libraries which have not been installed, and passing
-static-libtool-libs causes libtool to not do any dynamic linking
of libtool libraries at all.

In order to get libtool to actually link statically in all cases,
we should pass -all-static, not just -static.  However, because
too many platforms disallow static linking by default, this is
not a viable option.

If we retain the libtool archive librokenafs.la in the linker search
path, libtool then records the library dependency of libafshcrypto on
librokenafs in its metadata and refuses to install libafshcrypto.la to
any path other than the configured prefix.  This restriction of
libtool is incompatible with our use in 'make dest', and it is not
feasible to desupport 'make dest' before the 1.8 release.

The most appropriate workaround seems to be to just pass the
path to librokenafs.a on the linker command line when linking
build tools.  As such, provide a new make variable buildtool_roken
which is appropriate for linking roken into build tools -- this
variable will be set to the path to librokenafs.a when the internal
roken is used, and the normal -lrokenafs when an external roken
is used.

Change-Id: I079fc6de5d0aa6403eb1071f3d58a248b1777853
Reviewed-on: http://gerrit.openafs.org/11763
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams <3chas3@gmail.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

diff --git a/src/cf/roken.m4 b/src/cf/roken.m4
index 7426671..2766b43 100644 (file)
--- a/src/cf/roken.m4
+++ b/src/cf/roken.m4
@@ -4,6 +4,7 @@ AC_DEFUN([_OPENAFS_ROKEN_INTERNAL], [
   CPPFLAGS_roken=
   LDFLAGS_roken="-L\$(TOP_LIBDIR)"
   LIB_roken=-lrokenafs
+  buildtool_roken="\$(TOP_OBJDIR)/src/roken/librokenafs.a"
 ])
 
 dnl _OPENAFS_ROKEN_PATHS()
@@ -18,7 +19,8 @@ AC_DEFUN([_OPENAFS_ROKEN_PATHS], [
     [CPPFLAGS_roken="-I$roken_includedir"],
     [AS_IF([test x"$roken_root" != x],
       [CPPFLAGS_roken="-I$roken_root/include"])])
-  LIB_roken="-lroken"])
+  LIB_roken="-lroken"
+  buildtool_roken="$(LDFLAGS_roken) $(LIB_roken)"])
 
 dnl _OPENAFS_ROKEN_CHECK($action-if-found,
 dnl                     $action-if-not-found)
@@ -80,6 +82,7 @@ AC_DEFUN([OPENAFS_ROKEN], [
   AC_SUBST(CPPFLAGS_roken)
   AC_SUBST(LDFLAGS_roken)
   AC_SUBST(DIR_roken)
+  AC_SUBST(buildtool_roken)
 
   AC_ARG_WITH([roken],
     [AS_HELP_STRING([--with-roken=DIR],

diff --git a/src/config/Makefile.config.in b/src/config/Makefile.config.in
index 317dd25..e453531 100644 (file)
--- a/src/config/Makefile.config.in
+++ b/src/config/Makefile.config.in
@@ -63,6 +63,7 @@ LIB_crypt = @LIB_crypt@
 LIB_curses = @LIB_curses@
 LIB_hcrypto = @LIB_hcrypto@
 LIB_roken = @LIB_roken@
+buildtool_roken = @buildtool_roken@
 LIB_krb5 = @KRB5_LIBS@
 LIB_gssapi = @GSSAPI_LIBS@
 LIBTOOL= @LIBTOOL@