OpenAFS Master Repository branch, master, updated. openafs-devel-1_5_76-4760-g87ce2a6
Gerrit Code Review
Fri, 25 Dec 2015 02:18:29 -0500
The following commit has been merged in the master branch:
Author: Benjamin Kaduk <firstname.lastname@example.org>
Date: Wed Feb 25 18:46:28 2015 -0500
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
Tested-by: BuildBot <email@example.com>
Reviewed-by: Chas Williams <firstname.lastname@example.org>
Reviewed-by: Benjamin Kaduk <email@example.com>
src/cf/roken.m4 | 5 ++++-
src/config/Makefile.config.in | 1 +
2 files changed, 5 insertions(+), 1 deletions(-)
OpenAFS Master Repository