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 _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
