This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code
- From: Chuck Lever <chucklever at gmail dot com>
- To: Thorsten Kukuk <kukuk at suse dot de>
- Cc: libc-alpha at sourceware dot org, libtirpc List <libtirpc-devel at lists dot sourceforge dot net>
- Date: Mon, 6 Jul 2015 11:56:56 -0400
- Subject: Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code
- Authentication-results: sourceware.org; auth=none
- References: <20150624124457 dot GA7930 at suse dot de> <20150625100529 dot GQ17734 at vapier> <20150706123140 dot GB11315 at suse dot de>
Hi Thorsten-
> On Jul 6, 2015, at 8:31 AM, Thorsten Kukuk <kukuk@suse.de> wrote:
>
> On Thu, Jun 25, Mike Frysinger wrote:
>
>> pretty sure the --disable-obsolete-rpc flag already accomplishes this. the
>> problem is that libtirpc is not a full replacement yet for the API in glibc.
>
> Yes, I learned that now, too, even after fixing some functions
> and adding missing compat functions, there are still quite a lot
> of small, but important changes. Especially the naming of variables
> in structs :(
>
> Is there somewhere a list or something similar with the biggest problems
> found out when tryint to disable sunrpc in glibc by default?
> With my latest TI-RPC patches, I only see two remaining problems,
> both not solveable and needs adjustement in the applications:
> 1. programs trying to hook into svc_run().
> 2. different naming of some variables.
I’d like to hear details about both issues.
I think everyone on -devel wants to see a libtirpc on Linux that is
fully compatible with glibc. We are waiting for reports of the most
critical issues in this area, so please keep posting.
> The later may be solveable with some defines.
--
Chuck Lever
chucklever@gmail.com