On 2017-Apr-14, at 4:30 PM, Gerald Pfeifer <ger...@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@ 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]:


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 
./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:

 In function 'simple_object_internal_read':
 warning: implicit declaration of function 'read' 
       ssize_t got = read (descriptor, buffer, size);
 In function 'simple_object_internal_write':
 warning: implicit declaration of function 'write' 
       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

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to