On Jun 12, 2018, at 8:57 PM, Chuck Zmudzinski <frchuckz%gmail.com@localhost> wrote:
I already discovered 'build.sh release' fails on a NetBSD host with your new patch but without longlong_t and u_longlong_t in /usr/include/sys/types.h. It fails during the build of libc, so we do have to keep the u_longlong_t and longlong_t types in src/sys/sys/types.h.
I am optimistic that your new patch will successfully be able to do a 'build.sh release' on my Debian 8 host. I started the build and will check tomorrow morning to see if it succeeds. If it succeeds, then I can recommend your new patch to replace the first one. Otherwise, we may need to keep the fix in the tools/compat directory.
There are more problems. Per my just-moments-ago post on tech-toolchain:
----------------------------
revision 1.110
date: 2018-06-11 18:48:24 +0000; author: maya; state: Exp; lines: +5 -1; com
mitid: sW02GrA6eU9awTFA;
Add configure check and fallback definition for u_longlong_t
Should help linux tools compilation of dtrace tools, and not
affect NetBSD.
From Chuck Zmudzinski in current-users, with light modification
by myself.
----------------------------
This revision causes the following problem bootstrapping the tools on macOS:
# compile compat/atoll.lo
cc -O -no-cpp-precomp -I. -I./include -I/Users/thorpej/NetBSD/current/src/tools/compat -I/Users/thorpej/NetBSD/current/src/tools/compat/sys -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D__DBINTERFACE_PRIVATE -c -o atoll.lo.o /Users/thorpej/NetBSD/current/src/tools/compat/../../lib/libc/stdlib/atoll.c
In file included from /Users/thorpej/NetBSD/current/src/tools/compat/../../lib/libc/stdlib/atoll.c:33:
In file included from ./nbtool_config.h:885:
/Users/thorpej/NetBSD/current/src/tools/compat/compat_defs.h:72:9: error:
unknown type name 'uint64_t'
typedef uint64_t u_longlong_t;
The standard header that defines ‘uint64_t’ is <stdint.h>, but that isn’t bring brought into scope in this case.
Are we trying to protect against compilers that don’t grok “unsigned long long”?
Chuck Zmudzinski
On 06/12/2018 11:26 PM, Chuck Zmudzinski wrote:
Your new patch works for building tools on a NetBSD build host even without the u_longlong_t type defined in the build host's /usr/include/sys/types.h file. It also works on Debian Linux 8. Perhaps this patch will enable removal of the u_longlong_t and longlong_t data types from src/sys/sys/types.h which is installed as /usr/include/sys/types.h.
I am testing a 'build.sh release' overnight and will see if that succeeds without these data types in /usr/include/sys/types.h.
It might be desirable to remove these data types from the <sys/types.h> header file because /usr/include/sys/types.h adds this comment to discourage use of these data types:
/*
* The types longlong_t and u_longlong_t exist for use with the
* Sun-derived XDR routines involving these types, and their usage
* in other contexts is discouraged. Further note that these types
* may not be equivalent to "long long" and "unsigned long long",
* they are only guaranteed to be signed and unsigned 64-bit types
* respectively. Portable programs that need 64-bit types should use
* the C99 types int64_t and uint64_t instead.
*/
typedef int64_t longlong_t; /* for XDR */
typedef uint64_t u_longlong_t; /* for XDR */
Chuck Zmudzinski
On 06/12/2018 06:01 PM, maya%netbsd.org@localhost 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;
-- thorpej