On 12/14/2010 04:32 PM, Thomas Schwinge wrote: > Hallo! > > [Hurd people: this is about removing SUN RPC code from glibc, and use > libtirpc instead.] > > > On Tue, Dec 14, 2010 at 01:14:23PM -0500, Ulrich Drepper wrote: >> On Tue, Dec 14, 2010 at 11:26, Thomas Schwinge <tho...@schwinge.name> wrote: >>> To clarify: did you have anything specific in mind? I don't know why we >>> would want to diverge? >> >> The divergence would be there is Hurd doesn't use libtirpc. If Hurd >> does or will use libtirpc then there is no reason to diverge. > > I don't see any fundamental problems, so OK from my side, and we'll fix > issues as they occur. > > > In fact, I just had a look at > <git://git.infradead.org/~steved/libtirpc.git>'s master branch. (That's > the correct one to use, right?) > > It has very few specifc dependencies on Linux. These should be analyzed, > and probably handled differently. > > ./src/bindresvport.c:#ifdef __linux__ > ./src/clnt_dg.c:#include <linux/errqueue.h> > ./src/svc_auth_gss.c: /* ANDROS: change for debugging linux kernel > version... > > Building it with ``make -k'': > > ../../master/src/auth_unix.c:187: error: ‘MAXHOSTNAMELEN’ undeclared > (first use in this function) I don't understand what this is complaining about. Obviously MAXHOSTNAMELEN is define (see rpc/types.h) otherwise the non-hurd build would fail. Also, I've realized adding: #ifndef MAXHOSTNAMELEN #define MAXHOSTNAMELEN 64 #endif to auth_unix.c eliminates this "error". But again those ifdefs are not needed on "normal" builds so what gives? > > ../../master/src/bindresvport.c:189: error: ‘IPV6_PORTRANGE’ undeclared > (first use in this function) > ../../master/src/bindresvport.c:190: error: ‘IPV6_PORTRANGE_LOW’ > undeclared (first use in this function) This is true but these defines are in non-Linux code so I guess the hurd builds defines both Linux and non-Linux parts of the code?
> > ../../master/src/clnt_bcast.c:77:1: warning: "POLLRDNORM" redefined > In file included from /usr/include/sys/poll.h:26, > from ../../master/src/clnt_bcast.c:52: > /usr/include/bits/poll.h:32:1: warning: this is the location of the > previous definition > ../../master/src/clnt_bcast.c:78:1: warning: "POLLRDBAND" redefined > /usr/include/bits/poll.h:33:1: warning: this is the location of the > previous definition > > ../../master/src/clnt_vc.c:73:1: warning: "SCM_CREDS" redefined > In file included from /usr/include/sys/socket.h:40, > from ../../master/src/clnt_vc.c:55: > /usr/include/bits/socket.h:261:1: warning: this is the location of the > previous definition > ../../master/src/clnt_vc.c:82: error: redefinition of ‘struct cmsgcred’ These to are valid issues. The same code is defined in both a .c file and a header file. > > ../../master/src/rpc_soc.c: In function ‘clnt_com_create’: > ../../master/src/rpc_soc.c:108: error: ‘SOCK_CLOEXEC’ undeclared (first > use in this function) > ../../master/src/rpc_soc.c:108: error: (Each undeclared identifier is > reported only once > ../../master/src/rpc_soc.c:108: error: for each function it appears in.) Again these are defined through sys/socket.h (actually in bits/socket.h). So again I'm a bit confused as to what is needed... steved. > > That one is in my court -- I already have patches for SOCK_CLOEXEC et > al. for many months... > > ../../master/src/getpeereid.c: In function ‘getpeereid’: > ../../master/src/getpeereid.c:39: error: storage size of ‘uc’ isn’t known > ../../master/src/getpeereid.c:44: error: ‘SO_PEERCRED’ undeclared (first > use in this function) > ../../master/src/getpeereid.c:44: error: (Each undeclared identifier is > reported only once > ../../master/src/getpeereid.c:44: error: for each function it appears in.) > ../../master/src/getpeereid.c:39: warning: unused variable ‘uc’ > > All these seem fixable without too much effort, or we can resort to > disabling features we don't support yet. Do we have sombody volunteer > for working on that? (Please follow up on the Hurd lists only.) > > > Also, if libtirpc people (or anybody else) are interested in a shell > account for a GNU/Hurd system, please see > <http://www.gnu.org/software/hurd/public_hurd_boxen.html> or simply talk > to me. > > > Grüße, > Thomas -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d0929a6.8080...@redhat.com