OpenAFS Master Repository branch, master, updated. openafs-devel-1_5_76-4760-g87ce2a6

[Gerrit Code Review]

The following commit has been merged in the master branch:
commit 87ce2a6f05e313dad43311fba93224f33b86f54f
Author: Benjamin Kaduk <kaduk@mit.edu>
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
    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>

 src/cf/roken.m4               |    5 ++++-
 src/config/Makefile.config.in |    1 +
 2 files changed, 5 insertions(+), 1 deletions(-)

-- 
OpenAFS Master Repository