Re: ino64 package fallout

On Wed, May 24, 2017 at 05:49:04PM -0700, Don Lewis wrote:
> On 24 May, Konstantin Belousov wrote:
> > On Wed, May 24, 2017 at 10:05:22AM -0700, Don Lewis wrote:
> >> I just upgraded by package build box and its poudriere jail to r318776
> >> and ran into some significant package build fallout.
> > 
> > There are several reviews that fix ports with most significant fallouts,
> >    lang/llvm39			D10796
> >    lang/llvm40			D10797
> >    lang/ghc			D10798
> >    multimedia/webcamd		D10800
> >    devel/libgtop		D10795
> >    sysutils/py-psutil		D1081
> >    lang/rust			D10799
> > 
> > I intend to commit this tomorrow, after the ino64 get some probation time,
> > long enough to ensure that it does not get immediate revert.  You may
> > see the discussions and use the patches locally, meantime.
> 
> devel/libgtop is also broken:
> 
> procopenfiles.c:325:39: error: no member named 'kf_sa_local' in 'struct kinfo_file'
>                                 sun = (struct sockaddr_un *)&kif->kf_sa_local;
>                                                              ~~~  ^
> procopenfiles.c:330:37: error: no member named 'kf_sa_local' in 'struct kinfo_file'
>                                         addrstr = addr_to_string(&kif->kf_sa_local);
>                                                                   ~~~  ^
> procopenfiles.c:338:37: error: no member named 'kf_sa_peer' in 'struct kinfo_file'
>                                         addrstr = addr_to_string(&kif->kf_sa_peer);
>                                                                   ~~~  ^
> procopenfiles.c:352:36: error: no member named 'kf_sa_peer' in 'struct kinfo_file'
>                                 addrstr = addr_to_string(&kif->kf_sa_peer);
>                                                           ~~~  ^
> procopenfiles.c:357:52: error: no member named 'kf_sa_peer' in 'struct kinfo_file'
>                                 entry.info.sock.dest_port = addr_to_port(&kif->kf_sa_peer);
> procwd.c:155:16: warning: comparison of integers of different signs: 'int' and 'unsigned long' [-Wsign-compare]
>         for (i = 0; i < len / sizeof(*kif); i++, kif++) {
>                     ~ ^ ~~~~~~~~~~~~~~~~~~
>                                                                           ~~~  ^
> procopenfiles.c:388:9: warning: cast from 'gchar *' (aka 'char *') to 'glibtop_open_files_entry *' (aka 'struct _glibtop_open_files_entry *') increases required alignment from 1 to 4 [-Wcast-align]
>         return (glibtop_open_files_entry*)g_array_free(entries, FALSE);
>                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> procopenfiles.c:305:16: warning: comparison of integers of different signs: 'ssize_t' (aka 'long') and 'unsigned long' [-Wsign-compare]
>         for (i = 0; i < len / sizeof(*kif); i++, kif++) {
>                     ~ ^ ~~~~~~~~~~~~~~~~~~
> 2 warnings and 5 errors generated.

This looks like errors from the unpatched port.  For instance, in my
working directory, content of the file
devel/libgtop/work/libgtop-2.32.0/sysdeps/freebsd/procopenfiles.c
around line 325 is:
                                struct sockaddr_un *sun;
   
                                entry.type = GLIBTOP_FILE_TYPE_LOCALSOCKET;
                                sun = (struct sockaddr_un *)&kif->kf_un.kf_sock.
kf_sa_local;
which is not
	sun = (struct sockaddr_un *)&kif->kf_sa_local;
as reported by compiler in your case.

The patch is applied as extra-patch, might be you have OSVERSION set
forcibly ?