From owner-freebsd-toolchain@freebsd.org Fri Apr 14 01:39:01 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A458CD3D780 for ; Fri, 14 Apr 2017 01:39:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-43.reflexion.net [208.70.210.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 66D21E89 for ; Fri, 14 Apr 2017 01:39:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 595 invoked from network); 14 Apr 2017 01:38:59 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Apr 2017 01:38:59 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 13 Apr 2017 21:38:59 -0400 (EDT) Received: (qmail 15639 invoked from network); 14 Apr 2017 01:38:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Apr 2017 01:38:59 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7E3A5EC7901; Thu, 13 Apr 2017 18:38:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) From: Mark Millard In-Reply-To: Date: Thu, 13 Apr 2017 18:38:57 -0700 Cc: freebsd-arm , freebsd-head@freebsd.org, ericturgeon.bsd@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> References: To: Gerald Pfeifer , Pedro Giffuni , FreeBSD Ports , FreeBSD Toolchain X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 01:39:01 -0000 [I accidentally sent the original of the "on . . . wrote" below to the wrong toolchain list. This just corrects that.] [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 .] =3D=3D=3D Mark Millard markmi at dsl-only.net (I've added a missing "n" in the first "__nonnull_all" below.) On 2017-Apr-13, at 6:04 PM, Mark Millard wrote: > 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 . From owner-freebsd-toolchain@freebsd.org Fri Apr 14 02:30:51 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01ADED3D57F for ; Fri, 14 Apr 2017 02:30:51 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1.freebsd.org (Postfix) with SMTP id D3A13AEA for ; Fri, 14 Apr 2017 02:30:50 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: (qmail 83439 invoked by uid 99); 14 Apr 2017 02:30:49 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Apr 2017 02:30:49 +0000 Received: from [192.168.0.104] (unknown [190.157.139.67]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 0171A1A002E; Fri, 14 Apr 2017 02:30:47 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) From: Pedro Giffuni In-Reply-To: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> Date: Thu, 13 Apr 2017 21:32:14 -0500 Cc: Gerald Pfeifer , FreeBSD Ports , FreeBSD Toolchain , freebsd-arm , freebsd-head@freebsd.org, ericturgeon.bsd@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 02:30:51 -0000 > On Apr 13, 2017, at 20:38, Mark Millard 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 = 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 From owner-freebsd-toolchain@freebsd.org Fri Apr 14 20:41:08 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94564D3AA78 for ; Fri, 14 Apr 2017 20:41:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-41.reflexion.net [208.70.210.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3059B2F9 for ; Fri, 14 Apr 2017 20:41:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28864 invoked from network); 14 Apr 2017 20:41:00 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 14 Apr 2017 20:41:00 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 14 Apr 2017 16:41:00 -0400 (EDT) Received: (qmail 4139 invoked from network); 14 Apr 2017 20:41:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Apr 2017 20:41:00 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8E7A2EC7E2B for ; Fri, 14 Apr 2017 13:40:59 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: WITH_LLD_IS_LD vs default WITHOUT_SYSTEM_COMPILER: What are the reasons? Message-Id: Date: Fri, 14 Apr 2017 13:40:59 -0700 To: FreeBSD Toolchain X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 20:41:08 -0000 man src.conf (from -r315914 ) reports: WITH_LLD_IS_LD Set to use LLVM's LLD as the system linker, instead of GNU binutils ld. This is a default setting on arm64/aarch64. When set, these options are also in effect: WITHOUT_SYSTEM_COMPILER (unless WITH_SYSTEM_COMPILER is set explicitly) I'm curious about: A) Why there is a bias to avoid the system compiler? and by contrast: B) What sort of context justifies explicitly setting WITH_SYSTEM_COMPILER when WITH_LLD_IS_LD is in use? === Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Apr 14 21:35:08 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E6A8D3C00A for ; Fri, 14 Apr 2017 21:35:08 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AAAA976 for ; Fri, 14 Apr 2017 21:35:08 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:470:7a58::a52e:a92f:39e6:6900] (unknown [IPv6:2001:470:7a58:0:a52e:a92f:39e6:6900]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B62B62420E; Fri, 14 Apr 2017 23:35:05 +0200 (CEST) From: Dimitry Andric Message-Id: <7DB9F23E-2D55-44C3-AA91-C209BF584C4A@andric.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BE02AFEE-DF60-4B78-A153-AEC3C75C2C9D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: WITH_LLD_IS_LD vs default WITHOUT_SYSTEM_COMPILER: What are the reasons? Date: Fri, 14 Apr 2017 23:35:00 +0200 In-Reply-To: Cc: FreeBSD Toolchain To: Mark Millard References: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 21:35:08 -0000 --Apple-Mail=_BE02AFEE-DF60-4B78-A153-AEC3C75C2C9D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 14 Apr 2017, at 22:40, Mark Millard wrote: > > man src.conf (from -r315914 ) reports: > > WITH_LLD_IS_LD > Set to use LLVM's LLD as the system linker, instead of GNU > binutils ld. > > This is a default setting on arm64/aarch64. When set, these > options are also in effect: > > WITHOUT_SYSTEM_COMPILER (unless WITH_SYSTEM_COMPILER is set > explicitly) > > I'm curious about: > > A) Why there is a bias to avoid the system compiler? These are just the defaults, detected by the script that generates src.conf.5. The setting of MK_SYSTEM_COMPILER is actually dependent on the host, so it's technically incorrect to have src.conf.5 mention that it is off by default. > and by contrast: > > B) What sort of context justifies explicitly setting > WITH_SYSTEM_COMPILER when WITH_LLD_IS_LD is in use? The settings are mostly orthogonal. MK_SYSTEM_COMPILER was created to avoid building a bootstrap compiler, if the system (host) compiler is new enough. At some point you could also image a MK_SYSTEM_LINKER setting, which would avoid building the bootstrap linker, if the system linker is new enough. -Dimitry --Apple-Mail=_BE02AFEE-DF60-4B78-A153-AEC3C75C2C9D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljxQIkACgkQsF6jCi4glqN7jwCgzOzQK+lzSzcmbTPijcqe3qiu GRMAnA9dg08iVxz+kA28nvSaU8cI4Nsd =csZi -----END PGP SIGNATURE----- --Apple-Mail=_BE02AFEE-DF60-4B78-A153-AEC3C75C2C9D-- From owner-freebsd-toolchain@freebsd.org Fri Apr 14 23:30:58 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1B36D3E62D; Fri, 14 Apr 2017 23:30:58 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BAFAA8B8; Fri, 14 Apr 2017 23:30:58 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from anthias.catalysis.at (mail.catalysis.at [101.187.5.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ainaz.pair.com (Postfix) with ESMTPSA id 25DC03F530; Fri, 14 Apr 2017 19:30:52 -0400 (EDT) Date: Sat, 15 Apr 2017 09:30:49 +1000 (AEST) From: Gerald Pfeifer To: Pedro Giffuni , freebsd.contact@marino.st cc: Mark Millard , freebsd-ports@freebsd.org, freebsd-toolchain@freebsd.org, 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) In-Reply-To: Message-ID: References: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 23:30:59 -0000 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. Gerald PS: John, if you have an update, happy to help and apply that for you. From owner-freebsd-toolchain@freebsd.org Sat Apr 15 00:16:24 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D25C6D3D1ED for ; Sat, 15 Apr 2017 00:16:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-42.reflexion.net [208.70.210.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7EBE7D9F for ; Sat, 15 Apr 2017 00:16:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29984 invoked from network); 15 Apr 2017 00:17:24 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 15 Apr 2017 00:17:24 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 14 Apr 2017 20:16:22 -0400 (EDT) Received: (qmail 17723 invoked from network); 15 Apr 2017 00:16:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Apr 2017 00:16:21 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 49599EC7B2C; Fri, 14 Apr 2017 17:16:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: WITH_LLD_IS_LD vs default WITHOUT_SYSTEM_COMPILER: What are the reasons? From: Mark Millard In-Reply-To: <7DB9F23E-2D55-44C3-AA91-C209BF584C4A@andric.com> Date: Fri, 14 Apr 2017 17:16:14 -0700 Cc: FreeBSD Toolchain Content-Transfer-Encoding: 7bit Message-Id: References: <7DB9F23E-2D55-44C3-AA91-C209BF584C4A@andric.com> To: Dimitry Andric X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 00:16:24 -0000 On 2017-Apr-14, at 2:35 PM, Dimitry Andric wrote: > On 14 Apr 2017, at 22:40, Mark Millard wrote: >> >> man src.conf (from -r315914 ) reports: >> >> WITH_LLD_IS_LD >> Set to use LLVM's LLD as the system linker, instead of GNU >> binutils ld. >> >> This is a default setting on arm64/aarch64. When set, these >> options are also in effect: >> >> WITHOUT_SYSTEM_COMPILER (unless WITH_SYSTEM_COMPILER is set >> explicitly) >> >> I'm curious about: >> >> A) Why there is a bias to avoid the system compiler? > > These are just the defaults, detected by the script that generates > src.conf.5. The setting of MK_SYSTEM_COMPILER is actually dependent on > the host, so it's technically incorrect to have src.conf.5 mention that > it is off by default. Ahh. I took the mention of WITH_LLD_IS_LD and WITHOUT_SYSTEM_COMPILER as it was written as something that was being specially enforced, implying some form of lack of full independence. I wondered about what contexts trying WITH_SYSTEM_COMPILER might be broken when WITH_LLD_IS_LD was also in use. >> and by contrast: >> >> B) What sort of context justifies explicitly setting >> WITH_SYSTEM_COMPILER when WITH_LLD_IS_LD is in use? > > The settings are mostly orthogonal. MK_SYSTEM_COMPILER was created to > avoid building a bootstrap compiler, if the system (host) compiler is > new enough. I'm familiar with the WITH_SYSTEM_COMPILER vintage material have have been using it and other such things right along. My worry for my knowledge-base would be the "mostly" part of "mostly orthogonal": When is there a lack of independence? (Presuming system-clang 4.0 instead of system-gcc 4.2.1.) > At some point you could also image a MK_SYSTEM_LINKER setting, which > would avoid building the bootstrap linker, if the system linker is new > enough. Yep. So it sounds like I can freely mix WITH_LLD_IS_LD and WITH_SYSTEM_COMPILER in any system-clang 4.0 based system build context, no actual problem cases, even if the existing system build used a binutils ld (for example). Thanks for the information. === Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Apr 15 00:20:40 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 899BFD3D261; Sat, 15 Apr 2017 00:20:40 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A94BE16; Sat, 15 Apr 2017 00:20:40 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by mail-qk0-x244.google.com with SMTP id v75so13356708qkb.3; Fri, 14 Apr 2017 17:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version; bh=LlUPIyJB9UTXJENbMrNZQYTtVkJuUbKLv6uNX+kUc9U=; b=IJUNhbv/W6GEeZCXnh5Z1UDncLFVxfJJRLR6Bm+i/mp5CBKo0bllRi8rSkfAdvxCrq sT9Y5lO3jwV7oGu4KxpQ0D+8Tebft0PnI/6WfF+AKg6+6JtAPDZV3XOWsjcsvXID/Db0 EKhQuSYocWV62CVU/vseF4UI02JTFKEOV5CIgJ9Zv7aYyQxEIhVIZjGyb/tsTNCnnam9 F0/hjcGQecD7e1O0hxYXV9lZeFormeM3HNAhQsBC6owDgPsESlXeI2ge2X3bmamtUWlf OJ0FR84+cu2aGim6tufyBNmyzb4H7LyYzq6WNwyYYwSZO0IypmIp8jz2/IiPXP7oAqgY fQSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version; bh=LlUPIyJB9UTXJENbMrNZQYTtVkJuUbKLv6uNX+kUc9U=; b=sc0dUNc9aJRQDoQEna/sipNpB0CV91eq+bqqxLmUPATvVqA/Fdn1XEfF6sCOS6ebLc biKIW8DFuPwU600MM/6FqLCgQWj3UKmfmh8ox6IgAiIbfop3dL1uOTYm+3tG0o2fbRWV 7y8UFmaak1YWD5LYL8LxP5FP6e8Mz9WB1hLfnPBRIoXIlUplSE55AVLgHw02i+45jq63 gLMh5arHqgolDdQ0XQGSfDBuiu94ZE7fTSoxhF8fH2RWSzvtXHVxNtMo3Q706fPPvhMI vtynzqUJ7WRWh4MwRijxgJWr9us/e5e/KuBnv0/pgSClktK7m3n55dZTgxftLB6Ikhwi rjKg== X-Gm-Message-State: AN3rC/6w45kaU+bUb7XNCl171n0BuYYwulJ35a5+pduXg4nsdPLUuPtJ HEg2/TjqcAa2t5OY5O0= X-Received: by 10.55.157.3 with SMTP id g3mr161757qke.30.1492215639419; Fri, 14 Apr 2017 17:20:39 -0700 (PDT) Received: from kan ([2601:18f:802:4680:226:18ff:fe00:232e]) by smtp.gmail.com with ESMTPSA id t40sm2238368qtb.6.2017.04.14.17.20.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 14 Apr 2017 17:20:38 -0700 (PDT) Date: Fri, 14 Apr 2017 20:20:28 -0400 From: Alexander Kabaev To: Gerald Pfeifer Cc: Pedro Giffuni , freebsd-ports@freebsd.org, freebsd-toolchain@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: <20170414201952.69ccc472@kan> In-Reply-To: References: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/hXT+0F0LpnBeyNBKZqTkMUr"; protocol="application/pgp-signature" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 00:20:40 -0000 --Sig_/hXT+0F0LpnBeyNBKZqTkMUr Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On Sat, 15 Apr 2017 09:30:49 +1000 (AEST) Gerald Pfeifer 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. > >=20 > > 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. =20 >=20 > Indeed, thanks for the analysis/background, Pedro! >=20 > I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6,=20 > and perhaps John (as the maintainer of that port) has plans to update=20 > it? Let me copy him. >=20 > Gerald >=20 > PS: John, if you have an update, happy to help and apply that for you. Hi Gerald, it was suggested multiple times that the whole fixinc step is ultimately harmful and serves no useful purpose and probably should be disabled in built packages outright. Is there a reason not to do it? Even Redhat appears to do the slimming in their rpms: mv $FULLPATH/include-fixed/syslimits.h $FULLPATH/include/syslimits.h mv $FULLPATH/include-fixed/limits.h $FULLPATH/include/limits.h for h in `find $FULLPATH/include -name \*.h`; do if grep -q 'It has been auto-edited by fixincludes from' $h; then rh=3D`grep -A2 'It has been auto-edited by fixincludes from' $h | tail -1 | sed 's|^.*"\(.*\)".*$|\1|'` diff -up $rh $h || : rm -f $h fi done --=20 Alexander Kabaev --Sig_/hXT+0F0LpnBeyNBKZqTkMUr Content-Type: application/pgp-signature Content-Description: Цифровая подпись OpenPGP -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEExffZlZm2QeE8UVaRBxMimZJ5Ln4FAljxZ0xfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM1 RjdEOTk1OTlCNjQxRTEzQzUxNTY5MTA3MTMyMjk5OTI3OTJFN0UACgkQBxMimZJ5 Ln45nBAA1N6Du8J21LqGNKP37WTWqn6fLUeZaI9COJWPkVexi8Lb3bSuWA9KkuU5 vv/R57g4W21GaVuqI/6yRRCq6TFXpW+iXojxVbV2V1ix0U2hr0xPU7CLKk9LYnsk DHpbV8EVMSHYtuV188Ap2lqFJyXAOIn/s0Ymt/icz2HXyVpvpJ7PzhLQUZsjYnh/ J3WuJCAwBZA3F1LXKtl/a3iweiGpuxuOWfsYlwO6eTZerCop33qsLyq9UdPs6EEF z+KV1O08GzFh75wjtUlYSRTtX3N5EmoUivYHKUDwEJX3K7wPv4AUpyVmtpMnu+ns lc0nz7bErkhduoptEALbMpbyXfTdkiGc+hO9GpuTKYAgNcQTWMa9j7k9KY74WoDm T6vDXRg8VvyIQTyvl1cko+9nkTWXVsG5JR+uP5+ED27N9lwCEMDUccvm6qy/HKzc vE2gZzEtiNv9pd1S1OPyLJ2PNDGvoMVmjRIAU5lVLomLoyA69u/og/99Vyu+rGL4 Mb/+CLh+2i8M4cxTU99IR8/mJ+6qKDftaLBbRs/d+8F+8NomIdO2ioNu/+qcsddK fecmPyjanPd7+2KHrHqSCJw3GG3NhMRYy10konRRsM6MAfdU/1/HgwgbwDemxTkO ZV7CbctNwNxsprrBbHtmInPhJ94AJ59x+8RQ9NO00gI+YNwaSvw= =bti7 -----END PGP SIGNATURE----- --Sig_/hXT+0F0LpnBeyNBKZqTkMUr-- From owner-freebsd-toolchain@freebsd.org Sat Apr 15 02:53:49 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B6E2D3E1D9 for ; Sat, 15 Apr 2017 02:53:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-43.reflexion.net [208.70.210.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C20F810DC for ; Sat, 15 Apr 2017 02:53:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1089 invoked from network); 15 Apr 2017 02:53:46 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 15 Apr 2017 02:53:46 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 14 Apr 2017 22:53:46 -0400 (EDT) Received: (qmail 24506 invoked from network); 15 Apr 2017 02:53:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Apr 2017 02:53:46 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5D889EC78CC; Fri, 14 Apr 2017 19:53:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) From: Mark Millard In-Reply-To: Date: Fri, 14 Apr 2017 19:53:44 -0700 Cc: Pedro Giffuni , FreeBSD Ports , FreeBSD Toolchain , freebsd-arm , ericturgeon.bsd@gmail.com, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> To: Gerald Pfeifer X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 02:53:49 -0000 On 2017-Apr-14, at 4:30 PM, Gerald Pfeifer wrote: > On Thu, 13 Apr 2017, Pedro Giffuni wrote: >> 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. >>=20 >> 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. >=20 > Indeed, thanks for the analysis/background, Pedro! >=20 > I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6,=20= > and perhaps John (as the maintainer of that port) has plans to update=20= > 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/aarc= h64-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/s= imple-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/s= imple-object.c: In function 'simple_object_internal_read': = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c:75:21: warning: implicit declaration of function 'read' = [-Wimplicit-function-declaration] ssize_t got =3D read (descriptor, buffer, size); ^~~~ = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c: In function 'simple_object_internal_write': = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c:119:23: warning: implicit declaration of function 'write' = [-Wimplicit-function-declaration] ssize_t wrote =3D 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. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Apr 15 03:07:40 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B44A7D3E955; Sat, 15 Apr 2017 03:07:40 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D5FC20B; Sat, 15 Apr 2017 03:07:40 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg0-x243.google.com with SMTP id o123so18618139pga.1; Fri, 14 Apr 2017 20:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=F45sLgS5DdNiaxYMSXZhbG240fLI5g2HYPhd0FSj0DA=; b=nvK5lMBRg8px5VCy2+gGAAbqDXNbJZfsQtYQHaBvXyiL7NLa/2/70HtuposuUILZD5 JG6a7JT8TplH1kC9tw1N67kV1Zpv6aiqWGCEs7l59lYhoWlyp+XrKRNkf7p3YkQgBDKl Yn7PfchnZC03mMg3s7g5nT2lVWtvT5fl58BjVoBNlEwwqOv3J4LKwPL9Kxt5l+0dswSO RnJjd/Fwi5wOUkucq8/C8dE0fgwd9EHzkqDpuC/jiZp/JjolNsn66BZkBmz//masP69c MkWEGQcD/kUE2vIPite9aghZ6shWYaPr6kovxIC1/CMx0fhAT0mXxdQU9u6PRJAzV4f2 QWLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=F45sLgS5DdNiaxYMSXZhbG240fLI5g2HYPhd0FSj0DA=; b=d1TMCd87fLbloRdPHLhxZblgAgs0N02sngn8HFlKrRMvgBn1aJ6xZWlAs/cDFWYNZr tV1zsBSYgOaxzi6PmBgvzh2AF5BsMvpczJ++p4PNTeWlc3qXinWfW0M8QCDlu3+LXDM0 0oiOgKzi1iQQUsQ8CmlEBQiUDpkZoAUO9iQX4APFk1cpYXjdejYwukmbkZUL4LBV86RD Kr6KLrPIVptb7czZfbDCDCqddpQeit3hRfCwbtpICS6DV9eVAK+G9jtjMIyLhBmNdxHj Br+chtKNUAmD8BtZDuVQGMC8+Ly1eX8eaYjcbtbFPY5pfDOeoDI6K44R0BNn/wkYvhss SS8A== X-Gm-Message-State: AN3rC/47Q8RWGBBmIvwr946W/+YPwsJkGNkDTfpa5LEgltuI2/wkJ8iy nkKi+CUOzia+VA== X-Received: by 10.84.169.67 with SMTP id g61mr939580plb.51.1492225660005; Fri, 14 Apr 2017 20:07:40 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id l127sm5468287pga.7.2017.04.14.20.07.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 14 Apr 2017 20:07:39 -0700 (PDT) Subject: Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_534C68CC-3A27-411C-AB28-2AACB66F40B1"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: Date: Fri, 14 Apr 2017 20:07:37 -0700 Cc: Gerald Pfeifer , Pedro Giffuni , FreeBSD Ports , FreeBSD Toolchain , freebsd-arm , ericturgeon.bsd@gmail.com, FreeBSD Current Message-Id: <7606F976-20B7-4FB8-BE80-C27773F5529A@gmail.com> References: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 03:07:40 -0000 --Apple-Mail=_534C68CC-3A27-411C-AB28-2AACB66F40B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 14, 2017, at 19:53, Mark Millard wrote: >=20 > On 2017-Apr-14, at 4:30 PM, Gerald Pfeifer wrote: >=20 >> On Thu, 13 Apr 2017, Pedro Giffuni wrote: >>> 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. >>>=20 >>> 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. >>=20 >> Indeed, thanks for the analysis/background, Pedro! >>=20 >> 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. >=20 > [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.] >=20 > Just FYI: >=20 > [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.] >=20 >=20 > I tried using [on a Pine64+ 2GB aarch64 system]: >=20 > # = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/libexec/gcc/aarc= h64-aux-freebsd12.0/6.3.1/install-tools/mkheaders = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap >=20 > to deal with __nonnull, __nonnull_all, __vm_ooffset_t, and = __vm_pindex_t. >=20 > I then built via portmaster -CDK usage. Various header issues > did go away but the build of lang/gcc6-aux still stopped with: >=20 > In file included from = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c:20:0: > ./config.h:556:15: error: two or more data types in declaration = specifiers > #define pid_t int > ^ >=20 > I'm guessing that the define for pid_t in config.h resulted > in something like: >=20 > typedef ??? pid_t; >=20 > that turned into something like a: >=20 > typedef ??? int; >=20 > for the error listed above. >=20 > There were also implicit-declaration warnings: >=20 > = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c: In function 'simple_object_internal_read': > = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c:75:21: warning: implicit declaration of function 'read' = [-Wimplicit-function-declaration] > ssize_t got =3D read (descriptor, buffer, size); > ^~~~ > = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c: In function 'simple_object_internal_write': > = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c:119:23: warning: implicit declaration of function 'write' = [-Wimplicit-function-declaration] > ssize_t wrote =3D write (descriptor, buffer, size); > ^~~~~ >=20 > The implicit-declaration warnings for read and write may well > also not be expected/desirable. >=20 > 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 --Apple-Mail=_534C68CC-3A27-411C-AB28-2AACB66F40B1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY8Y56AAoJEPWDqSZpMIYVCqUQAJ3/RIVZHjUlbjtlq+eCNLiZ fk4l21s7AFvgMtRsqSulnEjPQywT+kcq/BIZUr7r+J9KRqIWu8uBIeZQ3znciXbS zH8LEfJFl/2Xy1ixCE3nJ1e4v/kP4CgeKLtiNVz4PgxA0rcqgucQLqWApC4QaRPl xe7/lLOTn1j9As4YaNErasU55JSzmlvGEQQb4HAKIR+/CX9qofekwj8cqtsdy7Bt dQ93H3HPVsJRHSbPDYt4zWfbGC//PZM28nEWVNguVKI21XIz68oToB9mWPdF7QVM qWCB7OfDoVHclKk4dmdNJe3Qz/qhDdYJQQd2T8i6q9qHE4xxuuTLlKx5J8KAxohd oM7ZEbqBMtddJA35g1nGwhBnIqcOITho+aDMaANYo7ykEUNpY2LFOtuxuBeSJpZ5 LgVXuRz4kopf4UHZ+XoNCI4EFWIFl/VpJd/rjpMkBgbn/Olu+6tNIyy6tZUB5BPn Cchu+5lmRaqTVtjjFbc0QS/SdXlRnoz2MA+xd+CvI2TDFXdoDS+amUU2keOPvkS+ nOb0h5exvPecvlnhhVQPgmLRnl6SJ4+N6MBt5l7Zfp5nc9lUMMK+1xo48guPd4E8 mLgozotLhXZIcRECl++g5dCm7x+7pYN/4+VHM9jd4YiRvZnnABj4+XaNlovukQAR yVjX49cZnKiT2FVMK3d5 =jZS8 -----END PGP SIGNATURE----- --Apple-Mail=_534C68CC-3A27-411C-AB28-2AACB66F40B1-- From owner-freebsd-toolchain@freebsd.org Sat Apr 15 03:27:32 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7741AD3E3F8 for ; Sat, 15 Apr 2017 03:27:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-41.reflexion.net [208.70.210.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26118A44 for ; Sat, 15 Apr 2017 03:27:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27743 invoked from network); 15 Apr 2017 03:30:30 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Apr 2017 03:30:30 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 14 Apr 2017 23:27:30 -0400 (EDT) Received: (qmail 20674 invoked from network); 15 Apr 2017 03:27:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Apr 2017 03:27:30 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7AFFEEC8B57; Fri, 14 Apr 2017 20:27:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) From: Mark Millard In-Reply-To: <7606F976-20B7-4FB8-BE80-C27773F5529A@gmail.com> Date: Fri, 14 Apr 2017 20:27:29 -0700 Cc: Gerald Pfeifer , Pedro Giffuni , FreeBSD Ports , FreeBSD Toolchain , freebsd-arm , ericturgeon.bsd@gmail.com, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> <7606F976-20B7-4FB8-BE80-C27773F5529A@gmail.com> To: "Ngie Cooper (yaneurabeya)" X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 03:27:32 -0000 On 2017-Apr-14, at 8:07 PM, Ngie Cooper (yaneurabeya) wrote: > 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 I got to lang/gcc6-aux indirectly: I saw the ports checkin notice and github information for ports-mgmt/synth indicating that native aarch64 support was now in place/possible. When I looked at what pkg would provide it was older. So on a Pine64+ 2GB [an aarch64 context] I did an svnlite update for /usr/ports and then tried to build ports-mgmt/synth . Synth is written in ada and so indirectly then attempts a lang/gcc6-aux build if it is not already in place. [gcc5-aux likely would not support aarch64.] I've no direct interest in lang/gcc6-aux or ada as stands. But indirectly such is involved in what I wanted to explore. I've seen material quoted from a exp-run that reported that about 54(?) ports were then blocked by lang/gcc6-aux not building. (So some problems might not be aarch64 specific despite my example context: the "54" material was likely not for an aarch64 context.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Apr 15 09:30:20 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 351F7D3F996; Sat, 15 Apr 2017 09:30:20 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "StartCom Class 2 IV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08FB71A5; Sat, 15 Apr 2017 09:30:19 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 030211F81; Sat, 15 Apr 2017 04:30:12 -0500 (CDT) Date: Sat, 15 Apr 2017 04:30:10 -0500 From: Mark Linimon To: Mark Millard Cc: "Ngie Cooper (yaneurabeya)" , Gerald Pfeifer , FreeBSD Ports , FreeBSD Current , FreeBSD Toolchain , freebsd-arm , Pedro Giffuni , 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: <20170415093010.GA4104@lonesome.com> References: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> <7606F976-20B7-4FB8-BE80-C27773F5529A@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 09:30:20 -0000 On Fri, Apr 14, 2017 at 08:27:29PM -0700, Mark Millard wrote: > I've seen material quoted from a exp-run that reported > that about 54(?) ports were then blocked by lang/gcc6-aux > not building. Although the first is an older run (the last complete run IIUC), there were 50 and 51 respectively as of: http://thunderx1.nyi.freebsd.org/build.html?mastername=110arm64-default&build=423029 http://beefy8.nyi.freebsd.org/build.html?mastername=head-armv6-default&build=p437390_s316341 I think you're fairly deep into unexplored territory here. mcl From owner-freebsd-toolchain@freebsd.org Sat Apr 15 14:54:02 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EB24D3FDC6; Sat, 15 Apr 2017 14:54:02 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2171758; Sat, 15 Apr 2017 14:54:01 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 2E9DB539B; Sat, 15 Apr 2017 14:54:01 +0000 (UTC) Date: Sat, 15 Apr 2017 14:54:01 +0000 From: Alexey Dokuchaev To: Matthew Rezny Cc: Dimitry Andric , Mark Millard , Johannes M Dieterich , FreeBSD Current , FreeBSD Toolchain , FreeBSD Ports , FreeBSD PowerPC ML Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Message-ID: <20170415145401.GH97090@FreeBSD.org> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <2502554.oHoOYGyFJH@workstation.reztek> <20170405161541.GA32323@FreeBSD.org> <2629274.jcOtFEnjsX@workstation.reztek> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2629274.jcOtFEnjsX@workstation.reztek> User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 14:54:02 -0000 Sorry Matthew, forgot to reply to this one. On Wed, Apr 05, 2017 at 07:01:35PM +0200, Matthew Rezny wrote: > On Wednesday 05 April 2017 16:15:41 Alexey Dokuchaev wrote: > > ... > > Hmm, I don't quite get it: shouldn't static linking actually increase > > the binaries (and thus the package) size? > > I might have reversed static and shared somewhere in the linking > explanation, or not properly described the situation. [...] Understood, makes sense now. > There was a brief period in which llvm39 was fully switched to dynamic > linking, which made it considerably smaller but caused runtime problems > (and was also likely to be slower). That still sounds like the most sane way to go; provided those problems are/would be fixed, I hope for that switch to happen again one day. (I somewhat doubt that "slower" was noticeable enough to worry about.) > The best solution to cut rebuild time for LLVM is ccache. Indeed, ccache helps greatly. Now that I've managed to cut down package times as well, situation with LLVM ports no longer looks as bad as I originally saw it; thank you. ./danfe