I just verified the current fix is not working on my Debian 8 build host, but rearranging the place where we add the typedef in compat_defs.h fixes it.

This new fix might be a better solution if we don't mind patching the "external" sources in the source tree. I wonder if there is a way to fix it by patching in the reachover part of the source tree.


In any case, I will test this new patch after reverting the previous one on my Debian 8 build host and see if it works. I should have an answer in less than an hour.

Chuck


On 06/12/2018 06:01 PM, m...@netbsd.org wrote:
blah, oops. Given the comment I'm not sure ulonglong_t is even
necessary, it doesn't appear anywhere.

Does reverting the previous and adding this (which upstream might
accept, they seem to just forget to remove it) help?

Works for building tools under netbsd.

Index: ./osnet/dist/uts/common/rpc/types.h
===================================================================
RCS file: /cvsroot/src/external/cddl/osnet/dist/uts/common/rpc/types.h,v
retrieving revision 1.2
diff -u -r1.2 types.h
--- ./osnet/dist/uts/common/rpc/types.h 10 Apr 2015 22:44:20 -0000      1.2
+++ ./osnet/dist/uts/common/rpc/types.h 12 Jun 2018 21:55:19 -0000
@@ -49,13 +49,6 @@
  typedef int bool_t;
  typedef int enum_t;
-/*
- * The ulonglong_t type was introduced to workaround an rpcgen bug
- * that has been fixed, this next typedef will be removed in a future release.
- * Do *NOT* use!
- */
-typedef u_longlong_t ulonglong_t;
-
  #if defined(_LP64) || defined(_I32LPx)
  typedef       uint32_t rpcprog_t;
  typedef       uint32_t rpcvers_t;


Reply via email to