> On Apr 14, 2017, at 19:53, Mark Millard <mar...@dsl-only.net> wrote:
> 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]:
> # 
> /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.

        Is there a reason why you need ada support (that seems to be the only 
real reason for installing gcc6 vs gcc6-aux)? gcc6-aux uses a snapshot of gcc6 
with custom options.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to