Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: More ctf fallout on a linux host

You are right - ulonglong_t is not necessary and I successfully built tools on Debian 8 after undoing your previous fix and replacing with your new patch of external/cddl/osnet/dist/uts/common/rpc/types.h.

I wonder if it is safe to remove u_longlong_t from <sys/types.h>. Linux does not have it, BSD does not need it. Does any modern software package use it?

Chuck Zmudzinski

On 06/12/2018 06:01 PM, 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;

Home | Main Index | Thread Index | Old Index