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. === Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"