Date: Thu, 13 Apr 2017 21:32:14 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Mark Millard <markmi@dsl-only.net> Cc: Gerald Pfeifer <gerald@FreeBSD.org>, FreeBSD Ports <freebsd-ports@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org>, freebsd-head@freebsd.org, ericturgeon.bsd@gmail.com Subject: Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) Message-ID: <E86AC2D1-EE2D-4E33-85FD-8069B050421F@FreeBSD.org> In-Reply-To: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> References: <E54E495A-E4C8-40B3-B1E8-133A9872B6B2@dsl-only.net> <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Apr 13, 2017, at 20:38, Mark Millard <markmi@dsl-only.net> wrote:
>=20
> [I accidentally sent the original of the "on . . . wrote"
> below to the wrong toolchain list. This just corrects that.]
>=20
> [I'll also note that lang/gcc6-aux was indirectly attempted
> when I tried to build ports-mgmt/synth on a Pine64+ 2GB
> (an aarch64 context). I had noticed the recent update claiming
> native aarch64 support for synth and tried to build it. I've
> no direct interest in lang/gcc6-aux . I just ended up with
> FYI information about lang/gcc6-aux .]
>=20
I didn=E2=80=99t 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 =E2=80=9Cfix=E2=80=9D 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.
Hope that helps,
Pedro.
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
>=20
> (I've added a missing "n" in the first "__nonnull_all" below.)
> On 2017-Apr-13, at 6:04 PM, Mark Millard <markmi at dsl-only.net> =
wrote:
>=20
>> As means of investigating if lang/gcc6-aux has other problems
>> building on aarch64 than just __nonnull and __nonnull_all I did:
>>=20
>> # svnlite diff /usr/src/sys/sys/
>> Index: /usr/src/sys/sys/cdefs.h
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> --- /usr/src/sys/sys/cdefs.h (revision 315914)
>> +++ /usr/src/sys/sys/cdefs.h (working copy)
>> @@ -376,6 +376,10 @@
>> #define __noinline
>> #endif
>>=20
>> +// HACK to enable older source that did not track.
>> +#define __nonnull(x)
>> +#define __nonnull_all
>> +
>> #if __GNUC_PREREQ__(3, 4)
>> #define __fastcall __attribute__((__fastcall__))
>> #define __result_use_check =
__attribute__((__warn_unused_result__))
>>=20
>> and so such similarly shows up in /usr/include/sys/cdefs.h .
>>=20
>> The attempt to build lang/gcc6-aux (as part of attempting
>> to build ports-mgmt/synth) resulted in:
>>=20
>>=20
>> In file included from =
/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/f=
dmatch.c:45:0:
>> ./config.h:556:15: error: two or more data types in declaration =
specifiers
>> #define pid_t int
>> ^
>> In file included from =
/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/f=
dmatch.c:49:0:
>> =
/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-=
aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:266:9: error: unknown =
type name '__vm_ooffset_t'
>> typedef __vm_ooffset_t vm_ooffset_t;
>> ^~~~~~~~~~~~~~
>> =
/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-=
aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:268:9: error: unknown =
type name '__vm_pindex_t'
>> typedef __vm_pindex_t vm_pindex_t;
>> ^~~~~~~~~~~~~
>> gmake[4]: *** [Makefile:732: fdmatch.o] Error 1
>> gmake[4]: Leaving directory =
'/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/build/libiberty'
>> gmake[3]: *** [Makefile:7458: all-libiberty] Error 2
>> gmake[3]: *** Waiting for unfinished jobs....
>>=20
>>=20
>> vm_ooffset_t and vm_pindex_t has 2017-Feb-4 changes:
>>=20
>> Revision 313194 - (view) (download) (annotate) - [select for diffs]=20=
>> Modified Sat Feb 4 12:26:38 2017 UTC (2 months, 1 week ago) by kib=20
>> File length: 10733 byte(s)=20
>> Diff to previous 299571
>> Define the vm_ooffset_t and vm_pindex_t types as machine-independend.
>>=20
>> The types are for the byte offset and page index in vm object. They
>> are similar to off_t, which is defined as 64bit MI integer. Using MI
>> definitions will allow to provide consistent MD values of vm
>> object-related maximum sizes.
>>=20
>> Reviewed by: alc
>> Sponsored by: The FreeBSD Foundation
>> MFC after: 1 week
>>=20
>>=20
>> The "#define pid_t int" in the local:
>>=20
>> =
/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/build/libiberty/config.h
>>=20
>> likely messes up some later "typedef . . . pid_t;", such as:
>>=20
>> =
/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-=
aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:typedef __pid_t =
pid_t; /* process id */
>>=20
>> resulting in:
>>=20
>> typedef __pid_t int;
>>=20
>>=20
>>=20
>> So lang/gcc6-aux bootstrapping has more problems than just __nonnull
>> and __nonnull_all issues, at least for aarch64 head.
>>=20
>> lang/gcc6-aux might not be the only thing with such issues.
>>=20
>>=20
>> I stopped with this. There could be more issues for lang/gcc6-aux .
>=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E86AC2D1-EE2D-4E33-85FD-8069B050421F>