rpcgen for uclibc

Kevin Day thekevinday at gmail.com
Tue Aug 11 13:13:52 UTC 2009


On Tue, Aug 11, 2009 at 2:45 AM, Natanael Copa<natanael.copa at gmail.com> wrote:
> 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
>

I believe xorg-server uses or supports "secure-rpc", with their
--enable-secure-rpc configure option.
I am assuming that secure RPC is the same RPC you are talking about,
is this correct?

However, this seems to be optional and may only deal with the remote
connections to xorg.


-- 
Kevin Day


More information about the uClibc mailing list