openafs/src/shlibafsauthent
Jeffrey Altman 1c12747818 Windows: Permit build system to update symbol store
Microsoft Debugging Tools for Windows, Visual Studio Debugger,
and SysInternals tools can all make use of a Symbol Server.
  http://msdn.microsoft.com/en-us/magazine/cc163563.aspx
The commit adds functionality to the build system to automatically
add binaries and symbols to a symbol store during the build.
This functionality is only enabled if two environment variables
are defined:

  SYMSTORE_EXE  - specifies the location of symstore.exe
  SYMSTORE_ROOT - specifies the location of the symbol store

an optional environment variable permits an arbitrary comment
to be added to the symbol store history file.

  SYMSTORE_COMMENT - arbitrary text to be added to the history

LICENSE MIT

Reviewed-on: http://gerrit.openafs.org/324
Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
Tested-by: Jeffrey Altman <jaltman@openafs.org>
2009-08-19 10:19:43 -07:00
..
afsauthent.def windows-shlibafsauthent-20080814 2008-08-15 00:37:20 +00:00
afsauthent.rc windows-file-versioning-20030619 2003-06-19 20:00:31 +00:00
libafsauthent.exp Make ktc_curpag generally available 2009-07-13 14:39:49 -06:00
libafsauthent.map Make ktc_curpag generally available 2009-07-13 14:39:49 -06:00
Makefile.in macos 10.6 updates 2009-08-14 11:58:49 -07:00
NTMakefile Windows: Permit build system to update symbol store 2009-08-19 10:19:43 -07:00
README

Copyright 2000, International Business Machines Corporation and others.
All Rights Reserved.

This software has been released under the terms of the IBM Public
License.  For details, see the LICENSE file in the top-level source
directory or online at http://www.openafs.org/dl/license10.html

This library is to be used by multithreaded programs that need to access
the kauth and auth library interfaces.  The primary method used to obtain
thread safety in these libraries is to lock/unlock a recursive global
mutex at the entry point of every public function in the library.

However, not all public functions are made thread safe since not all 
functions are needed by the NT admin work.  In particular, there are
many public functions that make up decendants of the functions
we wish to use that weren't modified, since these functions will be 
protected by the locking at a higher level function.

To prevent people from using non-thread safe functions, platform 
specific methods are used to limit the functions exported by the 
library (using def files under NT and mapfiles under Solaris).  For 
most non-exported functions, it should be trivial to make the 
transformation to thread safe by simply locking/ unlocking the 
global mutex at the beginning/end of the function.