Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

On 2017-Apr-14, at 4:30 PM, Gerald Pfeifer <gerald_at_pfeifer.com> wrote:

> On Thu, 13 Apr 2017, Pedro Giffuni wrote:
>> I didn’t want to get into this but the problem is that as part of it's
>> build/bootstrapping process, GCC historically takes system headers
>> and attempts to “fix” them. I am unsure the fixes do anything at all
>> nowadays but the effect is that the compiler tends to take snapshots
>> of the system headers when it is built. cdefs.h is used by all the
>> system headers so changes in cdefs.h have good chances affecting
>> such builds but any change are likely to cause similar trouble.
>> 
>> In the case of gcc-aux, it appears the compilation is based on a
>> bootstrap compiler which already carries outdated headers.
>> A workaround, suggested by gerald_at_ the last time a similar issue
>> happened was to run for install-tools/fixinc.sh. I think that may
>> regenerate the headers and let the build use updated headers.
>> Ultimately gcc-aux needs maintainer intervention and using
>> outdated headers will break sooner or later: especially on -current.
> 
> Indeed, thanks for the analysis/background, Pedro!
> 
> I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6, 
> and perhaps John (as the maintainer of that port) has plans to update 
> it?  Let me copy him.

[As I have a prior E-mail exchange with John M. indicating that
he was not intending to be the lang/gcc6-aux maintainer, I
avoid spamming him with this material: I've removed him from
the CC list in this reply. I can send the material to him if I
see evidence of his wanting it.]

Just FYI:

[Previously: temporarily adding __nonnull and __nonnull_all
back into into my local head FreeBSD variant got problems
with: __vm_ooffset_t and __vm_pindex_t no longer existing and
also the same pid_t issue indicated below.]


I tried using [on a Pine64+ 2GB aarch64 system]:

# /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/libexec/gcc/aarch64-aux-freebsd12.0/6.3.1/install-tools/mkheaders /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap

to deal with __nonnull, __nonnull_all, __vm_ooffset_t, and __vm_pindex_t.

I then built via portmaster -CDK usage. Various header issues
did go away but the build of lang/gcc6-aux still stopped with:

In file included from /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:20:0:
./config.h:556:15: error: two or more data types in declaration specifiers
 #define pid_t int
               ^

I'm guessing that the define for pid_t in config.h resulted
in something like:

typedef ??? pid_t;

that turned into something like a:

typedef ??? int;

for the error listed above.

There were also implicit-declaration warnings:

/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c: In function 'simple_object_internal_read':
/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:75:21: warning: implicit declaration of function 'read' [-Wimplicit-function-declaration]
       ssize_t got = read (descriptor, buffer, size);
                     ^~~~
/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c: In function 'simple_object_internal_write':
/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/simple-object.c:119:23: warning: implicit declaration of function 'write' [-Wimplicit-function-declaration]
       ssize_t wrote = write (descriptor, buffer, size);
                       ^~~~~

The implicit-declaration warnings for read and write may well
also not be expected/desirable.

It may be that more than a script run is needed to make
things be appropriate.

===
Mark Millard
markmi at dsl-only.net