rpcgen for uclibc

Natanael Copa natanael.copa at gmail.com
Tue Aug 11 07:45:00 UTC 2009


I'm cleaning up my inbox and I had missed this. sorry.

On Wed, 2009-07-22 at 20:58 -0400, Mike Frysinger wrote:

> i dont think it's the C libraries' business to provide the rpcgen binary.  
> yes, i know glibc provides it, but they've deprecated all of the rpc stuff in 
> the C library.  if they could get away with it, they'd punt all of the rpc 
> code, but ABI compatibility holds them back.  everyone is moving to libtirpc 
> for their rpc needs since the glibc maintainers are refusing to update the rpc 
> code (most importantly IPv6 support, but not limited to that).
> 
> i'm not sure how far we should take this in uClibc ... punt the code 
> altogether ?  disable it by default and add #warning's to the code and add 
> info to the Kconfig (eventually punting it) ?

Would be nice to get rid of it yes. I think we could disable by default,
add #warning's for next release and punt it alltogether the release
after that again. 

> what realistic consumers are there of the rpc code ?  of course there is nfs-
> utils and related (rpcbind), but those have transitioned to libtirpc already.
> -mike

IIRC the berkely db also uses (used?) rpc. I suppose we could check up
if db can use libtirpc.

If there are no more packages than nfs-utils and db and both can use
other libs, I'd say just punt rpc stuff.

-nc



More information about the uClibc mailing list