[OpenAFS-devel] symbol _error_message conflict on 10.3

[Dave Botsch]

Right...

what's more interesting is that under 10.4, stuff builds. It appears that using
the 10.4SDK, xcode is able to do its two level namespace trick and just gives
an ld warning that that symbol is there multiple times.

Under 10.3SDK, however, (even when building on a 10.4 box), it seems that this
doesn't work, even if I specify the twolevel namespace linker option. So,
something is different under 10.3, but what? Could it have something to do w.
the way the afs libs or the kerberos framework is built under 10.3?

thanks.

On Mon, Feb 19, 2007 at 07:45:45PM -0500, Marcus Watts wrote:
> > 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
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
> 

-- 
********************************
David William Botsch
Programmer/Analyst
CNF Computing
botsch@cnf.cornell.edu
********************************