> 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.
Thanks!
-Ngie
signature.asc
Description: Message signed with OpenPGP using GPGMail
