2007/8/30, Frederik Deweerdt <[EMAIL PROTECTED]>: > On Thu, Aug 30, 2007 at 04:50:51PM +0200, Eric Noulard wrote: > > I've updated the bug. > > I think I found the reason. > > > > We are linked again glibc ONC-RPC whereas we may/should link > > against tirpc. > The libs have the same name isn't it?
No in fact they don't. Current glibc aka libc.[a|so] include rpclib API (<rpc/rpc.h>) tirpc is named libtirpc.[a.so] and "seems" (as far as I understand) to be API compatible. > Are they binary compatible? More or less. The short answer is NO you need to recompile+relink. But yes since "old" rpc lib should be able to use the new implementation of rpc services, the portmapper. Since it "should" be compatible I did file a bug to rpcbind: http://sourceforge.net/tracker/index.php?func=detail&aid=1784838&group_id=201237&atid=976751 More detailed answer follows: Our [classical] usage of ONC-RPC is twofold 1) the RPC lib which is an implementation of the API you find in <rpc/rpc.h>. the libs includes XDR encoding API xdr_xxx see: xdr(3) and rpc(3) ftp://ftp.rfc-editor.org/in-notes/rfc1057.txt (ONC-RPC v2) ftp://ftp.rfc-editor.org/in-notes/std/std67.txt (XDR) 2) the RPC portmapper service specified both in ftp://ftp.rfc-editor.org/in-notes/rfc1057.txt (ONC-RPC v2) and in a revised form in ftp://ftp.rfc-editor.org/in-notes/rfc1833.txt (RPCBIND for ONC-RPC v2) The portmapper is implemented as a unix daemon (or Windows service). In the same package you usually get the rpcinfo command for inspecting the RPC server(s) currently registered in the portmapper. see portmap(8) and/or rpcbind(8) and rpcinfo(8) We are linked with the lib 1) and we call 2) the portmapper through the rpc lib 1). With the "Old fashioned" ONC-RPC 1) lib rpc is in glibc 2) the portmapper is called portmap With the "New" TI-RPC 1) lib rpc is a standalone /usr/lib/libtirpc.so.1 2) the portmapper is called rpcbind Even more detailed info about TI-RPC in: "ONC+ Developer's Guide" (doc Solaris 10) de Sun http://docs-pdf.sun.com/816-1435/816-1435.pdf > If not, shouldn't this be implemented as a new command transport layer > (a la xmlrpc)? May be interesting since in TI-RPC, TI means Transport Independent current target of Transport are IPV4 (UDP and TCP) and IPV6 (UDP and TCP). The main motivation of TI-RPC seems to be NFSv4 which NEEDS IPV6 support which was not taken into account in ONC-RPC. That said I don't know if we should "replace" onc-rpc with ti-rpc in the long run or add ti-rpc as a supplementary default command transport layer. I would say that for backward compatibility reason adding a new ti-rpc handler would be better. I've just discovered the TI idea and I would say that this is almost the "same" functional idea as our multi-command transport layer (oncrpc, xml-rpc etc...) -- Erk _______________________________________________ Tsp-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tsp-devel
