A bit of background in case any one wonders why I'm doing silly things
like editing object files :-)

When I wanted to add crypto hooks to things like ftp, which use stdio,
my original plan was to simply replace filbuf and flsbuf with ones
that would call the crypto code as needed.

This of course proved impossible to do portably since flsbuf is
usually in the same object file as fflush and quite a few other key
parts of stdio.

So I dug out some stdio code I wrote many years ago for MS-DOS and
updated it with the necessary crypto hooks, all works nicely.  But it
means I have to force all the macro calls of getc() and putc() to be
functions - so I can hide my implementation details...

So, back to my original plan, but this time I got more devious.
I extract read.o, write.o and close.o from libc.a and edit the
symbols to something very unlikely to be in use (wRiTe,rEaD,cLoSe) and
I can now provide my own read,write and close routines which call
wRiTe et al for normal file descriptors.

So far I have tested this approach on NetBSD, SunOS and Solaris and it
works, but on NetBSD 1.2D (i386 if that matters) I get: 

ld: /usr/local/src/sjg/lib/obj/libsslfd.a(write_.o): RRS text relocation at 0xed45 for "cerror"
ld: /usr/local/src/sjg/lib/obj/libsslfd.a(read_.o): RRS text relocation at 0xed59 for "cerror"
ld: /usr/local/src/sjg/lib/obj/libsslfd.a(close_.o): RRS text relocation at 0xf609 for "cerror"

and I'd like to know why.  My little tool which edits the object is
careful not to touch anything except the _read,_write etc
symbols, and nm shows:

$ nm obj/read_.o 
00000008 T _rEaD
         U cerror

which looks fine (cf read.o)

Can anyone suggest a solution?  I know I have source for NetBSD, but
the idea was to have a solution that simply hacked object files out of
libc... I'd prefer not to have to special case NetBSD.

Thanks

--sjg