Re: bin/40574: netbsd-4 builds fail on netbsd-5 hosts (nbmtree issues)

[christos%zoulas.com@localhost (Christos Zoulas)]

On Feb 8,  3:50am, oster%cs.usask.ca@localhost (Greg Oster) wrote:
-- Subject: Re: bin/40574: netbsd-4 builds fail on netbsd-5 hosts (nbmtree is

|  It doesn't. 
|  
|  But I can replicate this on amd64 XEN_DOMU from today's 5.0_RC1 when 
|  trying to build for netbsd-4 i386.
|  
|  In a nutshell, the prototype for user_from_uid() (and others) 
|  don't get pulled in because they are protected by 
|  #if defined(_NETBSD_SOURCE)
|  in /usr/include/pwd.h and that #define isn't set when building mtree 
|  as a tool.  If one looks closely when doing the build, one sees:
|  
|  /u1/builds/c/src/tools/mtree/../../usr.sbin/mtree/spec.c: In function 
'dump_nodes':
|  /u1/builds/c/src/tools/mtree/../../usr.sbin/mtree/spec.c:334: warning: 
assignment makes pointer from integer without a cast
|  /u1/builds/c/src/tools/mtree/../../usr.sbin/mtree/spec.c:341: warning: 
assignment makes pointer from integer without a cast
|  
|  (among other similar errors in mtree).  If I hack the Makefile a bit 
|  I can get a version that crashes and has symbols.  What I end up with 
|  is:
|  
|  Core was generated by `mtree'.
|  Program terminated with signal 11, Segmentation fault.
|  #0  0x00007f7ffd9caf7a in strlen () from /usr/lib/libc.so.12
|  (gdb) where
|  #0  0x00007f7ffd9caf7a in strlen () from /usr/lib/libc.so.12
|  #1  0x00007f7ffd9c3c2d in __vfprintf_unlocked () from /usr/lib/libc.so.12
|  #2  0x00007f7ffd9c4d44 in vfprintf () from /usr/lib/libc.so.12
|  #3  0x00007f7ffd9c003e in printf () from /usr/lib/libc.so.12
|  #4  0x0000000000406a88 in dump_nodes (dir=0x40f13f "", root=0x7f7ffd81d180, 
|      pathlast=0) at 
/u1/builds/c/src/tools/mtree/../../usr.sbin/mtree/spec.c:335
|  #5  0x0000000000405f42 in main (argc=0, argv=0x7f7fffffdc38)
|      at /u1/builds/c/src/tools/mtree/../../usr.sbin/mtree/mtree.c:211
|  (gdb) up
|  #1  0x00007f7ffd9c3c2d in __vfprintf_unlocked () from /usr/lib/libc.so.12
|  (gdb) up
|  #2  0x00007f7ffd9c4d44 in vfprintf () from /usr/lib/libc.so.12
|  (gdb) up
|  #3  0x00007f7ffd9c003e in printf () from /usr/lib/libc.so.12
|  (gdb) up
|  #4  0x0000000000406a88 in dump_nodes (dir=0x40f13f "", root=0x7f7ffd81d180, 
|      pathlast=0) at 
/u1/builds/c/src/tools/mtree/../../usr.sbin/mtree/spec.c:335
|  335                                     printf("uname=%s ", name);
|  (gdb) list
|  330                     if (MATCHFLAG(F_TYPE))
|  331                             printf("type=%s ", nodetype(cur->type));
|  332                     if (MATCHFLAG(F_UID | F_UNAME)) {
|  333                             if (keys & F_UNAME &&
|  334                                 (name = user_from_uid(cur->st_uid, 1)) 
!= NULL)
|  335                                     printf("uname=%s ", name);
|  336                             else
|  337                                     printf("uid=%u ", cur->st_uid);
|  338                     }
|  339                     if (MATCHFLAG(F_GID | F_GNAME)) {
|  (gdb) print name
|  $1 = 0xfffffffffd4b2704 <Address DEFANGED_0xfffffffffd4b2704 DEFANGED_out 
DEFANGED_of DEFANGED_bounds>
|  
|  which, of course, is going to go 'boom' when passed to printf.
|  
|  The fix, of course, is to pull in the correct prototype for 
|  user_from_uid() and assorted other functions (there are other build 
|  errors if one looks close -- I can provide a list if needed), but I'm 
|  not sure what the right mechanism is for doing that in the land of build 
|  tools...
|  

This was fixed in a long time ago, but the changes were not pulled up to 4.x

christos