Date: Fri, 14 Apr 2017 19:53:44 -0700 From: Mark Millard <markmi@dsl-only.net> To: Gerald Pfeifer <gerald@pfeifer.com> Cc: Pedro Giffuni <pfg@FreeBSD.org>, FreeBSD Ports <freebsd-ports@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org>, ericturgeon.bsd@gmail.com, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) Message-ID: <FA9D3BB0-E5DA-4DAE-BA61-01BFCFBCC24C@dsl-only.net> In-Reply-To: <alpine.LNX.2.21.1704150928320.4604@anthias.pfeifer.com> References: <E54E495A-E4C8-40B3-B1E8-133A9872B6B2@dsl-only.net> <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> <E86AC2D1-EE2D-4E33-85FD-8069B050421F@FreeBSD.org> <alpine.LNX.2.21.1704150928320.4604@anthias.pfeifer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Apr-14, at 4:30 PM, Gerald Pfeifer <gerald@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.
===
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FA9D3BB0-E5DA-4DAE-BA61-01BFCFBCC24C>