Re: More build.sh ctf fallout on a linux host
My recent tests verify this new patch of a single file in src/external/cddl/osnet/dist/uts/common/rpc/types.h to replace the earlier patch of 4 files in src/tools/compat fixes both the build of tools and release using build.sh on Debian 8 build host. With the recent commits it looks like everything should be working well again on Debian Linux hosts... Chuck Zmudzinski On 06/13/2018 12:02 AM, Jason Thorpe wrote: On Jun 12, 2018, at 8:57 PM, Chuck Zmudzinski 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 +; 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 , 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 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. */ typedefint64_tlonglong_t;/* for XDR */ typedefuint64_tu_longlong_t;/* for XDR */ Chuck Zmudzinski 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.h10 Apr 2015 22:44:20 -1.2 +++ ./osnet/dist/uts/common/rpc/types.h12 Jun 2018 21:55:19 - @@ -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) typedefuint32_t rpcprog_t; typedefuint32_t rpcvers_t; -- thorpej
Re: More build.sh ctf fallout on a linux host
The build is now working again on my Debian 9 host - thanks. -- Andreas Gustafsson, g...@gson.org
Re: More build.sh ctf fallout on a linux host
Hopefully replacing the old patch with the new patch will also fix the problem on MacOS... Chuck Zmudzinski On 06/13/2018 12:02 AM, Jason Thorpe wrote: On Jun 12, 2018, at 8:57 PM, Chuck Zmudzinski 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 +; 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 , 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 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. */ typedefint64_tlonglong_t;/* for XDR */ typedefuint64_tu_longlong_t;/* for XDR */ Chuck Zmudzinski 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.h10 Apr 2015 22:44:20 -1.2 +++ ./osnet/dist/uts/common/rpc/types.h12 Jun 2018 21:55:19 - @@ -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) typedefuint32_t rpcprog_t; typedefuint32_t rpcvers_t; -- thorpej
Re: More build.sh ctf fallout on a linux host
> On Jun 12, 2018, at 8:57 PM, Chuck Zmudzinski 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 +; 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 , 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 >> 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. >> */ >> >> typedefint64_tlonglong_t;/* for XDR */ >> typedefuint64_tu_longlong_t;/* for XDR */ >> >> Chuck Zmudzinski >> >> >> 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.h10 Apr 2015 22:44:20 -1.2 >>> +++ ./osnet/dist/uts/common/rpc/types.h12 Jun 2018 21:55:19 - >>> @@ -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) >>> typedefuint32_t rpcprog_t; >>> typedefuint32_t rpcvers_t; >>> >> > -- thorpej
Re: More build.sh ctf fallout on a linux host
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. 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 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, 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 - 1.2 +++ ./osnet/dist/uts/common/rpc/types.h 12 Jun 2018 21:55:19 - @@ -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;
Re: More build.sh ctf fallout on a linux host
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 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, 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 - 1.2 +++ ./osnet/dist/uts/common/rpc/types.h 12 Jun 2018 21:55:19 - @@ -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;
Re: More build.sh ctf fallout on a linux host
On 06/12/2018 08:50 PM, Chuck Zmudzinski wrote: 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 . Linux does not have it, BSD does not need it. Does any modern software package use it? Actually it appears u_longlong_t is needed in some of the cddl software, but since now it can build on Linux systems that do not define that type in the system file, I wonder if it is necessary to have that type defined in NetBSD's system file, which is src/sys/sys/types.h in the source tree or /usr/include/sys/types.h in an installed system. In the build of tools on a Linux build host, it appears the u_longlong_t is defined from the header files in src/external/cddl/osnet/sys/sys and does not depend on u_longlong_t being defined in /usr/include/sys/types.h. Chuck Zmudzinski Chuck Zmudzinski 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 - 1.2 +++ ./osnet/dist/uts/common/rpc/types.h 12 Jun 2018 21:55:19 - @@ -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;
Re: More build.sh 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 . 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, 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 - 1.2 +++ ./osnet/dist/uts/common/rpc/types.h 12 Jun 2018 21:55:19 - @@ -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;
Re: More build.sh ctf fallout on a linux host
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 - 1.2 +++ ./osnet/dist/uts/common/rpc/types.h 12 Jun 2018 21:55:19 - @@ -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;
Re: More build.sh ctf fallout on a linux host
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 - 1.2 +++ ./osnet/dist/uts/common/rpc/types.h 12 Jun 2018 21:55:19 - @@ -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) typedefuint32_t rpcprog_t; typedefuint32_t rpcvers_t;
Re: More build.sh ctf fallout on a linux host
The first thing to try is to do the build with a completely empty object directory. If that doesn't fix it... Based on the error messages during the build of tools in build.sh on systems missing the u_longlong_t type, I think the build might fail with the committed patch because the messages seemed to indicate the u_longlong_t type needs to be defined before is included ( includes , and is the header that does not have the u_longlong_t type on some Linux systems). In compat_defs.h, is included at line 75, but the typedef for u_longlong_t is added at line 1302. In the patch I tested with a successful build on a Debian 8 system that also did not have the u_longlong_t type, I placed the typedef for u_longlong_t between lines 74 and 75 of compat_defs.h instead of at line 1302, where it is placed in the committed patch. Although it seems logical to place the missing typedef at the same place in compat_defs.h that take care of any other missing type definitions that belong in , I am not sure that placement in the compat_defs.h file actually fixes the build of tools on Linux systems. I don't know if this means the build of that component of tools (ctf, libctf) using build.sh is not including header files in the expected order. Chuck Zmudzinski On 06/12/2018 04:01 AM, Andreas Gustafsson wrote: m...@netbsd.org wrote: Thanks, I committed that. The build still fails on my Debian 9 system after that commit. The configure script prints checking for u_longlong_t... no and the build later fails with: --- ctf_create.lo --- In file included from /bracket/build/2018.06.11.18.48.25-i386/src/tools/libctf/../compat/compat_defs.h:75:0, from /bracket/build/2018.06.11.18.48.25-i386/tools/include/compat/nbtool_config.h:885, from /bracket/build/2018.06.11.18.48.25-i386/src/tools/libctf/../../external/cddl/osnet/dist/common/ctf/ctf_create.c:23: /bracket/build/2018.06.11.18.48.25-i386/src/tools/libctf/../../external/cddl/osnet/dist/uts/common/rpc/types.h:57:9: error: unknown type name 'u_longlong_t' typedef u_longlong_t ulonglong_t; ^~~~
Re: More build.sh ctf fallout on a linux host
m...@netbsd.org wrote: > Thanks, I committed that. The build still fails on my Debian 9 system after that commit. The configure script prints checking for u_longlong_t... no and the build later fails with: --- ctf_create.lo --- In file included from /bracket/build/2018.06.11.18.48.25-i386/src/tools/libctf/../compat/compat_defs.h:75:0, from /bracket/build/2018.06.11.18.48.25-i386/tools/include/compat/nbtool_config.h:885, from /bracket/build/2018.06.11.18.48.25-i386/src/tools/libctf/../../external/cddl/osnet/dist/common/ctf/ctf_create.c:23: /bracket/build/2018.06.11.18.48.25-i386/src/tools/libctf/../../external/cddl/osnet/dist/uts/common/rpc/types.h:57:9: error: unknown type name 'u_longlong_t' typedef u_longlong_t ulonglong_t; ^~~~ -- Andreas Gustafsson, g...@gson.org
Re: More build.sh ctf fallout on a linux host
On Thu, Jun 07, 2018 at 06:47:13AM -0400, Chuck Zmudzinski wrote: > Hello, Thanks, I committed that. I tried to match compat_defs.h's existing style better.
Re: More build.sh ctf fallout on a linux host
Hello, I have a solution for this problem on my Debian system, it should also work for Ubuntu or OpenSuSE. The problem comes from the fact that the new version of cddl recently imported requires the u_longlong_t type to be set, and it is in on NetBSD and probably also on Fedora, since I think someone reported Fedora works. But it is missing in Debian, Ubuntu, and OpenSuSE. Quick fix for the impatient: Apply the attached patch and you should now be able to build on the Linux hosts. More detailed description of the fix: 1. Follow the procedure in src/tools/compat/configure.ac for editing that file, which starts with building the tools with the option to build the maintainer tools: autoconf and autoheader. You will need to do this on a system that is able to build tools, such as a NetBSD build host. 2. Edit src/tools/compat/configure.ac so the build system checks for the u_longlong_t type, and if it does not exist, add the typedef that is missing in the appropriate place, which is in src/tools/compat/compat_defs.h. 3. After those two files are edited properly, such as according to the attached patch, then follow the procedure to regenerate the configure script and the nbtool_config.h.in file. 4. The attached patch includes all the modifications to the four modified files that are needed to apply the fix, which I tested on both a NetBSD system and a Debian system that previously failed because of the missing typedef. I hope this can be fixed soon. Chuck Zmudzinski On 06/05/2018 06:49 AM, Joerg Sonnenberger wrote: On Mon, Jun 04, 2018 at 10:52:03AM +0300, Valery Ushakov wrote: On Sun, Jun 03, 2018 at 18:16:47 -0700, Chuck Silvers wrote: /home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/uts/common/rpc/types.h:57:9: error: unknown type name 'u_longlong_t' typedef u_longlong_t ulonglong_t; ^ I was afraid that might happen... which distribution and version of linux was that on? the one I did my fix for linux on was fedora 26. Sorry, I should have been specific. It's on Ubuntu 16.04 LTS. ...and last regular OpenSuSE release as well. Joerg --- src/tools/compat/configure.ac 2017-12-08 23:22:53.0 -0500 +++ src/tools/compat/configure.ac 2018-06-07 05:19:39.399367000 -0400 @@ -97,6 +97,7 @@ # Typedefs. AC_TYPE_SIZE_T AC_CHECK_TYPES([id_t, long long, u_long, u_char, u_short, u_int, u_quad_t]) +AC_CHECK_TYPES([u_longlong_t],,, [#include ]) AC_CHECK_TYPE(socklen_t, [AC_DEFINE([HAVE_SOCKLEN_T], 1, [Define if you have the socklen_t type.])],, [#include --- src/tools/compat/compat_defs.h 2017-10-02 21:43:03.0 -0400 +++ src/tools/compat/compat_defs.h 2018-06-07 05:19:43.423882000 -0400 @@ -72,6 +72,11 @@ #endif #if HAVE_RPC_TYPES_H +/* Some Linux build hosts don't have this in + * This type is needed since import of new version of cddl */ +#ifndef HAVE_U_LONGLONG_T +typedef uint64_t u_longlong_t; +#endif #include #endif --- src/tools/compat/configure 2017-12-08 23:23:22.0 -0500 +++ src/tools/compat/configure 2018-06-07 05:19:57.588742000 -0400 @@ -4227,6 +4227,17 @@ fi +ac_fn_c_check_type "$LINENO" "u_longlong_t" "ac_cv_type_u_longlong_t" "#include +" +if test "x$ac_cv_type_u_longlong_t" = xyes; then : + +cat >>confdefs.h <<_ACEOF +#define HAVE_U_LONGLONG_T 1 +_ACEOF + + +fi + ac_fn_c_check_type "$LINENO" "socklen_t" "ac_cv_type_socklen_t" "#include #ifdef HAVE_RPC_TYPES_H #include @@ -5012,8 +5023,6 @@ # ifdef _MSC_VER # include # define alloca _alloca -# elif defined(__NetBSD__) || defined(__FreeBSD__) || defined(__DragonFly__) || defined(__OpenBSD__) -# include # else # ifdef HAVE_ALLOCA_H # include --- src/tools/compat/nbtool_config.h.in 2017-12-08 23:23:22.0 -0500 +++ src/tools/compat/nbtool_config.h.in 2018-06-07 05:19:57.0 -0400 @@ -1,6 +1,6 @@ /* nbtool_config.h.in. Generated from configure.ac by autoheader. */ -/* $NetBSD: nbtool_config.h.in,v 1.42 2017/12/09 04:23:22 sevan Exp $ */ +/* $NetBSD$*/ #ifndef __NETBSD_NBTOOL_CONFIG_H__ #define __NETBSD_NBTOOL_CONFIG_H__ @@ -780,6 +780,9 @@ /* Define to 1 if the system has the type `u_long'. */ #undef HAVE_U_LONG +/* Define to 1 if the system has the type `u_longlong_t'. */ +#undef HAVE_U_LONGLONG_T + /* Define to 1 if the system has the type `u_quad_t'. */ #undef HAVE_U_QUAD_T
Re: More build.sh ctf fallout on a linux host
On Mon, Jun 04, 2018 at 10:52:03AM +0300, Valery Ushakov wrote: > On Sun, Jun 03, 2018 at 18:16:47 -0700, Chuck Silvers wrote: > > > > /home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/uts/common/rpc/types.h:57:9: > > > error: unknown type name 'u_longlong_t' > > > typedef u_longlong_t ulonglong_t; > > > ^ > > > > I was afraid that might happen... > > which distribution and version of linux was that on? > > the one I did my fix for linux on was fedora 26. > > Sorry, I should have been specific. It's on Ubuntu 16.04 LTS. ...and last regular OpenSuSE release as well. Joerg
Re: More build.sh ctf fallout on a linux host
On 06/04/2018 05:52 PM, Chuck Zmudzinski wrote:
Hello,
I am also seeing this same error when cross-compiling the tools on a
Linux Debian Jessie amd64 (oldstable) build host for a netbsd-current
amd64/x86_64 target. I started with a completely empty object tree and
a cvs checkout of current as of Mon Jun 4 18:00:00 UTC 2018. The last
commit that was included in my source is this one on Mon Jun 4
16:46:46 UTC 2018:
http://mail-index.netbsd.org/source-changes/2018/06/04/msg095742.html.
That was the commit that noted the import of a new version of dhcpcd
in src/doc. I will test the same source tree on a NetBSD-7.1 amd64
build host and see if it can build the tools on that host.
This snapshot from earlier today does build tools successfully for
netbsd-current/amd64 on a NetBSD-7.1 amd64 build host. It looks like at
least older Debian-derived amd64 linux is not able to build tools for
netbsd-current/amd64 using build.sh right now. The Debian I used with
the failed build is an up-to-date Jessie, which is currently Debian
8.10. Debian Jessie 8.0 was released April 26, 2015, and is considered
obsolete now by Debian. Ubuntu 16.04 LTS is a about a year newer, it was
initially released April 21, 2016 and is supported until April 2021. I
do have a newer Debian stretch which is the current up-to-date Debian
stable release, version 9.4, and I could try the build on that.
Chuck
Here is a snippet form my log of the build failure:
# compile libctf/ctf_create.lo
...
In file included from
/home/chuckz/netbsd-current/src/tools/libctf/../compat/compat_defs.h:75:0,
from
/home/chuckz/netbsd-current/obj.amd64/home/chuckz/netbsd-current/src/tooldir.Linux-3.16.0-6-amd64-x86_64/include/compat/nbtool_config.h:882,
from
/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/dist/common/ctf/ctf_create.c:23:
/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/dist/uts/common/rpc/types.h:57:9:
error: unknown type name 'u_longlong_t'
typedef u_longlong_t ulonglong_t;
^
*** Failed target: ctf_create.lo
*** Failed command: cc -O -DCTF_OLD_VERSIONS
-I/home/chuckz/netbsd-current/src/tools/libctf/../compat
-I/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/sys
-I/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/include
-I/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/dist/head
-I/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/dist/common/ctf
-I/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/dist/lib/libctf/common
-I/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/dist/uts/common
-I/home/chuckz/netbsd-current/src/tools/libctf/../../external/bsd/elftoolchain/dist/libelf
-DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64
-I/home/chuckz/netbsd-current/obj.amd64/home/chuckz/netbsd-current/src/tooldir.Linux-3.16.0-6-amd64-x86_64/include/compat
-I/home/chuckz/netbsd-current/src/tools/compat
-DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64
-I/home/chuckz/netbsd-current/obj.amd64/home/chuckz/netbsd-current/src/tooldir.Linux-3.16.0-6-amd64-x86_64/include
-I/home/chuckz/netbsd-current/obj.amd64/home/chuckz/netbsd-current/src/tooldir.Linux-3.16.0-6-amd64-x86_64/include/nbinclude
-c -o ctf_create.lo.o
/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/dist/common/ctf/ctf_create.c
*** Error code 1
Stop.
nbmake[3]: stopped in /home/chuckz/netbsd-current/src/tools/libctf
*** Failed target: dependall
*** Failed command: cd "/home/chuckz/netbsd-current/src/tools/libctf";
/home/chuckz/netbsd-current/obj.amd64/home/chuckz/netbsd-current/src/tooldir.Linux-3.16.0-6-amd64-x86_64/bin/nbmake
realall
*** Error code 1
Stop.
nbmake[2]: stopped in /home/chuckz/netbsd-current/src/tools/libctf
*** Failed target: dependall-libctf
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
this=""; real="/home/chuckz/netbsd-current/src/tools" ;; *)
this="${dir}/"; real="/home/chuckz/netbsd-current/src/tools/${dir}" ;;
esac; show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with:
$@)}"; cd "${real}" &&
/home/chuckz/netbsd-current/obj.amd64/home/chuckz/netbsd-current/src/tooldir.Linux-3.16.0-6-amd64-x86_64/bin/nbmake
_THISDIR_="${this}" "$@" ${target}; }; _makedirtarget libctf dependall
*** Error code 1
Stop.
nbmake[1]: stopped in /home/chuckz/netbsd-current/src/tools
*** Failed target: build_install
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
this=""; real="/home/chuckz/netbsd-current/src/tools" ;; *)
this="${dir}/"; real="/home/chuckz/netbsd-current/src/tools/${dir}" ;;
esac; show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with:
$@)}"; cd "${real}" &&
Re: More build.sh ctf fallout on a linux host
Hello,
I am also seeing this same error when cross-compiling the tools on a
Linux Debian Jessie amd64 (oldstable) build host for a netbsd-current
amd64/x86_64 target. I started with a completely empty object tree and a
cvs checkout of current as of Mon Jun 4 18:00:00 UTC 2018. The last
commit that was included in my source is this one on Mon Jun 4 16:46:46
UTC 2018:
http://mail-index.netbsd.org/source-changes/2018/06/04/msg095742.html.
That was the commit that noted the import of a new version of dhcpcd in
src/doc. I will test the same source tree on a NetBSD-7.1 amd64 build
host and see if it can build the tools on that host.
Here is a snippet form my log of the build failure:
# compile libctf/ctf_create.lo
...
In file included from
/home/chuckz/netbsd-current/src/tools/libctf/../compat/compat_defs.h:75:0,
from
/home/chuckz/netbsd-current/obj.amd64/home/chuckz/netbsd-current/src/tooldir.Linux-3.16.0-6-amd64-x86_64/include/compat/nbtool_config.h:882,
from
/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/dist/common/ctf/ctf_create.c:23:
/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/dist/uts/common/rpc/types.h:57:9:
error: unknown type name 'u_longlong_t'
typedef u_longlong_t ulonglong_t;
^
*** Failed target: ctf_create.lo
*** Failed command: cc -O -DCTF_OLD_VERSIONS
-I/home/chuckz/netbsd-current/src/tools/libctf/../compat
-I/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/sys
-I/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/include
-I/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/dist/head
-I/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/dist/common/ctf
-I/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/dist/lib/libctf/common
-I/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/dist/uts/common
-I/home/chuckz/netbsd-current/src/tools/libctf/../../external/bsd/elftoolchain/dist/libelf
-DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64
-I/home/chuckz/netbsd-current/obj.amd64/home/chuckz/netbsd-current/src/tooldir.Linux-3.16.0-6-amd64-x86_64/include/compat
-I/home/chuckz/netbsd-current/src/tools/compat -DHAVE_NBTOOL_CONFIG_H=1
-D_FILE_OFFSET_BITS=64
-I/home/chuckz/netbsd-current/obj.amd64/home/chuckz/netbsd-current/src/tooldir.Linux-3.16.0-6-amd64-x86_64/include
-I/home/chuckz/netbsd-current/obj.amd64/home/chuckz/netbsd-current/src/tooldir.Linux-3.16.0-6-amd64-x86_64/include/nbinclude
-c -o ctf_create.lo.o
/home/chuckz/netbsd-current/src/tools/libctf/../../external/cddl/osnet/dist/common/ctf/ctf_create.c
*** Error code 1
Stop.
nbmake[3]: stopped in /home/chuckz/netbsd-current/src/tools/libctf
*** Failed target: dependall
*** Failed command: cd "/home/chuckz/netbsd-current/src/tools/libctf";
/home/chuckz/netbsd-current/obj.amd64/home/chuckz/netbsd-current/src/tooldir.Linux-3.16.0-6-amd64-x86_64/bin/nbmake
realall
*** Error code 1
Stop.
nbmake[2]: stopped in /home/chuckz/netbsd-current/src/tools/libctf
*** Failed target: dependall-libctf
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="";
real="/home/chuckz/netbsd-current/src/tools" ;; *) this="${dir}/";
real="/home/chuckz/netbsd-current/src/tools/${dir}" ;; esac;
show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd
"${real}" &&
/home/chuckz/netbsd-current/obj.amd64/home/chuckz/netbsd-current/src/tooldir.Linux-3.16.0-6-amd64-x86_64/bin/nbmake
_THISDIR_="${this}" "$@" ${target}; }; _makedirtarget libctf dependall
*** Error code 1
Stop.
nbmake[1]: stopped in /home/chuckz/netbsd-current/src/tools
*** Failed target: build_install
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="";
real="/home/chuckz/netbsd-current/src/tools" ;; *) this="${dir}/";
real="/home/chuckz/netbsd-current/src/tools/${dir}" ;; esac;
show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd
"${real}" &&
/home/chuckz/netbsd-current/obj.amd64/home/chuckz/netbsd-current/src/tooldir.Linux-3.16.0-6-amd64-x86_64/bin/nbmake
_THISDIR_="${this}" "$@" ${target}; }; _makedirtarget . dependall-libctf
*** Error code 1
Stop.
nbmake: stopped in /home/chuckz/netbsd-current/src/tools
ERROR: Failed to make build_install in "tools"
*** BUILD ABORTED ***
Chuck
On 06/04/2018 03:52 AM, Valery Ushakov wrote:
On Sun, Jun 03, 2018 at 18:16:47 -0700, Chuck Silvers wrote:
/home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/uts/common/rpc/types.h:57:9:
error: unknown type name 'u_longlong_t'
typedef u_longlong_t ulonglong_t;
^
I was afraid that might happen...
which distribution and version of linux was that on?
the one I did my fix for linux on was fedora 26.
Sorry, I should have been
Re: More build.sh ctf fallout on a linux host
On Sun, Jun 03, 2018 at 18:16:47 -0700, Chuck Silvers wrote: > > /home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/uts/common/rpc/types.h:57:9: > > error: unknown type name 'u_longlong_t' > > typedef u_longlong_t ulonglong_t; > > ^ > > I was afraid that might happen... > which distribution and version of linux was that on? > the one I did my fix for linux on was fedora 26. Sorry, I should have been specific. It's on Ubuntu 16.04 LTS. -uwe
Re: More build.sh ctf fallout on a linux host
On Sun, Jun 03, 2018 at 10:27:06PM +0300, Valery Ushakov wrote: > # compile libctf/ctf_error.lo > cc -pipe -O2 -DCTF_OLD_VERSIONS > -I/home/uwe/work/netbsd/ro/src/tools/libctf/../compat > -I/home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/sys > -I/home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/include > > -I/home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/head > > -I/home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/common/ctf > > -I/home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/lib/libctf/common > > -I/home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/uts/common > > -I/home/uwe/work/netbsd/ro/src/tools/libctf/../../external/bsd/elftoolchain/dist/libelf > -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 > -I/home/uwe/work/netbsd/build/tools/include/compat > -I/home/uwe/work/netbsd/ro/src/tools/compat -DHAVE_NBTOOL_CONFIG_H=1 > -D_FILE_OFFSET_BITS=64 -I/home/uwe/work/netbsd/build/tools/include > -I/home/uwe/work/netbsd/build/tools/include/nbinclude -c -o ctf_error.lo.o > /home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/common/ctf/ctf_error.c > In file included from > /home/uwe/work/netbsd/ro/src/tools/libctf/../compat/compat_defs.h:75:0, > from > /home/uwe/work/netbsd/build/tools/include/compat/nbtool_config.h:882, > from > /home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/common/ctf/ctf_error.c:23: > /home/uwe/work/netbsd/ro/src/tools/libctf/../../external/cddl/osnet/dist/uts/common/rpc/types.h:57:9: > error: unknown type name 'u_longlong_t' > typedef u_longlong_t ulonglong_t; > ^ I was afraid that might happen... which distribution and version of linux was that on? the one I did my fix for linux on was fedora 26. -Chuck
