[OpenAFS-GK] Re: [OpenAFS-win32-devel] rxk5 openafs for windows work in progress--seems to work

[Derrick J Brashear]

On Tue, 2 Jan 2007, Marcus Watts wrote:

> ...
>>> //2 - com_err issues.
>>> 	Each of these might exist and is likely to be an afs issue in a
>>> 	given environment.  They all has gratuitous incompatibilities, and
>>> 	often also depending on version & build configuration:
>>> 		e2fsprogs	- tytso, debian linux
>>> 		heimdal		- kth, various
>>> 		mit		- from source for unix,
>>> 				also windows, macosx, solaris
>>> 	and especially (!) openafs
>>>
>>> 	problems include:
>>> 		compiling error tables
>>
>> Where is compiling a problem?
>
> You mean entirely inside openafs today, linking external things
> against openafs, or in tomorrow's bright shiny new world?

Yes.

> Today, openafs comes with its own compile_et, which is of
> course 100% compatible with the comerr that's inside of openafs.
> No problem.  :-)
>
> Linking external things against openafs means using the same compile_et
> that came with openafs.  That's a packaging decision, which means

Actually, I don't think it does.

> In tomorrow's shiny new world?  Maybe openafs shouldn't be providing
> its own com_err but should instead link against some external comerr.
> That means using somebody else's compile_et.  This could either be very
> very good, or very very bad.

We talked about this. There's even a list which was for all relevant 
parties. It just never got done.

> You're got this slightly confused with lower-case base names.
> Yes, it's good the lower-case thing was fixed.
> The special errors & non-standard bases are
> 	-457	rxgen		afs/rxgen_const.h
> 	-8	rx		rx/rx.h
> 	101	vice

Special errors, not really non-standard bases.