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