search for: typdef

...Server 3.0, socklen_t this typedef doesn't exist on SCO OSR 3, and "configure" properly detects this, leading to /* #undef HAVE_SOCKLEN_T */ in config.h. Problem: I can't find any place where this is actually being used? I'd expect something like #ifndef HAVE_SOCKLEN_T typdef int socklen_t; #endif ("int" is what the relevant functions use here, checked vs. the man pages) - but there isn't anything. Which would be the "right" header file to add such things? Then I'll just do it and send in a patch with all the necessary changes for SCO OSR...

...hanged, 19 insertions(+), 13 deletions(-) diff --git a/src/nv_local.h b/src/nv_local.h index 5a74ee2..d0a89c7 100644 --- a/src/nv_local.h +++ b/src/nv_local.h @@ -43,7 +43,7 @@ /* * This file includes any environment or machine specific values to access the - * HW. Put all affected includes, typdefs, etc. here so the riva_hw.* files + * HW. Put all affected includes, typdefs, etc. here so the nv_hw.* files * can stay generic in nature. */ #include "compiler.h" @@ -52,16 +52,16 @@ /* * HW access macros. These assume memory-mapped I/O, and not normal I/O space. */ -#defin...

Hi, I got this. configure: WARNING: sys/un.h: present but cannot be compiled configure: WARNING: sys/un.h: check for missing prerequisite headers? configure: WARNING: sys/un.h: see the Autoconf documentation configure: WARNING: sys/un.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/un.h: proceeding with the preprocessor's result configure: WARNING:

Reid, >Well, if it doesn't break anything else, I'd fix the header file. The >standard type name is supposed to uint64_t not u_int64_t. I would just >change the header file to define both of them, something like: > >typedef u_int64_t uint64_t; > >You could do that in /usr/include/types.h, I've tried it and it doesn't break anything, but ... >or we could

...ure tests wether it's running on the Interix platform (__INTERIX >>set). >>2) Add ifdef'd typedef u_int64_t uint64_t; in llvm/include/Config.h and >>possible other required values/types for LLVM. > >I think that there should be a general test for u_int64_t and then typdef >it if uint64_t doesn't exist. I have a feeling Interix isn't the only >platform that doesn't support uint<x>_t (I seem to recall that AIX doesn't >either). > >-- John T. > >> >> >>/Henrik >> >>_______________________________...

>From Apple's xdr.h: "If your code invokes an xdrproc_t callback, it must be modified to pass a third parameter, which may simply be zero." --- src/proto.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/proto.c b/src/proto.c index 92ae84d..57f4882 100644 --- a/src/proto.c +++ b/src/proto.c @@ -252,7 +252,12 @@ guestfs___send (guestfs_h *g, int proc_nr, *