On Mon, Dec 14, 2020 at 7:14 PM Nikhil Benesch <nikhil.bene...@gmail.com> wrote:
>
> On 12/14/20 5:30 AM, Rainer Orth wrote:
> > with the revised godump.c patch and this one for mk*sysinfo.sh, I still
> > get failures on all of Solaris 11.3/x86, 11.4/x86, and 11.4/SPARC
> > (didn't try 11.3/SPARC):
> >
> > * Solaris 11.3/x86 and 11.4/x86:
> >
> > runtime_sysinfo.go:5995:6: error: redefinition of '_upad128_t'
> >
> > gen-sysinfo has
> >
> > // type _upad128_t struct { _q INVALID-float-80; Godump_0_pad [4]byte; }
> > type _upad128_t struct {}
> >
> > and mk*sysinfo.sh adds
> >
> > type _upad128_t struct { _l [4]uint32; }
> >
> > * Solaris 11.4/SPARC and x86:
> >
> > runtime_sysinfo.go:1178:55: error: use of undefined type '_in6_addr_t'
> >
> > runtime_sysinfo.go uses _in6_addr_t in _flow_arp_desc_s,
> > _flow_l3_desc_s, _mac_ipaddr_s, _mac_resource_props_s, and
> > _mactun_info_s, but there's no definition and you've removed the
> > section of mk*sysinfo.sh to replace it by [16]byte.
> >
> > The issue is here, I believe:
> >
> > + -e 's/\([^a-zA-Z0-9_]\)_in6_addr\([^a-zA-Z0-9_]\)/\1[16]byte\2/g' \
> > + -e 's/\([^a-zA-Z0-9_]\)_in6_addr$/\1[16]byte/g' \
> >
> > Neither line matches _in6_addr_t. Removing '_' from the second char
> > set on the first line fixes this, but I'm unsure what exactly this is
> > going to match on different systems.
> >
> > Rainer
> >
>
> Sigh. Thanks. Perhaps the attached will work.
>
> (I'm still waiting on my own compilation to complete. Compilation on
> gcc211 is glacial. I wonder if I'm doing something wrong.)
>
> The idea is to just rewrite both _in_addr and _in_addr_t. Perhaps
> someone smarter than me can figure out how to write a simpler set
> of basic REs.
>
> Also godump now emits a dummy `type _u?pad128_t struct {}` entry,
> so we just suppress that and conditionally add it back.
I don't understand this bit. Why are we seeing an empty struct
definition, and why is this change the right fix?
Is the problem that because we don't know how to emit the definition
of the struct, godump.c winds up emitting an empty definition? That
doesn't sound like the right thing to do for this case.
Ian
