[OpenAFS-devel] symbol _error_message conflict on 10.3

Marcus Watts mdw@umich.edu
Mon, 19 Feb 2007 19:45:45 -0500


> From: Dave Botsch <botsch@cnf.cornell.edu>
> To: openafs-devel@openafs.org
> Subject: [OpenAFS-devel] symbol _error_message conflict on 10.3
> Sender: openafs-devel-admin@openafs.org
> Errors-To: openafs-devel-admin@openafs.org
> Date: Mon, 19 Feb 2007 17:46:31 -0500
> 
> So, I'm getting a linker error on Mac OS X 10.3 ...
> 
> the symbol _error_message is defined both in Kerberos.framework and in
> libafsrpc.a (error_msg.o) -- any thoughts on how to resolve this?
> 
> thanks.

Welcome to the "com_err" mess.  Com_err was intended to be a
portable way for multiple libraries to share a common table to
map error numbers into error strings.  It has a couple of
global variables and structures that make it all work.
These include "struct error_table" and "struct et_list _et_list".
Originally, compile_et generated code that at runtime knew
about _et_list and did no locking.  Newer implementations may instead
provide for this, add_error_table or add_to_error_table or remove_error_table or
initialize_error_table or initialize_error_table_r ...
These may have provisions for locking.

And then there are the implementations...

error_message() in the MIT k5 code is contained in libcom_err.a.
The search mechanism uses the upper 24 bits to map against error
table bases.  Recent versions of MIT k5 require that -lk5support
be linked in after com_err, for code necesssary to make
optional pthread locking work.

error_message() in the AFS code is contained in libcom_err.a.
The error_message code also knows that negative error numbers are
special (ie, not looked up), and that several ranges both positive
and negative correspond to special AFS error ranges and are
processed using separate special code.  For pthread code,
error_msg() is contained inside of libafsrpc.  For both pthread
and non-pthread code, _et_list is private.

The apple version of MIT k5 combines libkrb5, libk5crypto, libcom_err,
and libk5support into one thing.  It also uses a private interface
based on mig to access the local credentials cache, and special
magic (presumably some sort of run-at-load-time function)
to make error tables auto-initialize.

heimdal and e2progs also provide implementations of comerr which
won't be so much of an issue for the Macintosh.

So, ...
if you link against libafsrpc.a and not libafsrpc.dylib, that
may be one solution.  You won't get the afs special error messages.
You might need to copy libafsrpc.a and delete err_msg.o from it,
and you might have other problems that will need to be resolved
with more hacks.

I don't think there's any easy option to modify the MacOS X
kerberos dylib to do anything different.

you could link in heimdal - you'll need to build that & make
sure it does something sensible about error tables (it can
be configured several different ways.)  It maps in the MacOS X
kerberos dylib to access the actual credentials cache.

I believe in the future the plan is for openafs & mit & others to
have code that plays better together.  openafs+rxk5 includes
reworked code in src/comerr that is intended to play better with
other code, which is intended to be a start at that.

					-Marcus Watts