Date: Sat, 15 Apr 2017 09:30:49 +1000 (AEST) From: Gerald Pfeifer <gerald@pfeifer.com> To: Pedro Giffuni <pfg@FreeBSD.org>, freebsd.contact@marino.st Cc: Mark Millard <markmi@dsl-only.net>, 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) Message-ID: <alpine.LNX.2.21.1704150928320.4604@anthias.pfeifer.com> In-Reply-To: <E86AC2D1-EE2D-4E33-85FD-8069B050421F@FreeBSD.org> References: <E54E495A-E4C8-40B3-B1E8-133A9872B6B2@dsl-only.net> <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> <E86AC2D1-EE2D-4E33-85FD-8069B050421F@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <owner-freebsd-toolchain@freebsd.org> 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 <freebsd-toolchain@mailman.ysv.freebsd.org>; 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 <freebsd-toolchain@freebsd.org>; 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 <markmi@dsl-only.net> In-Reply-To: <7DB9F23E-2D55-44C3-AA91-C209BF584C4A@andric.com> Date: Fri, 14 Apr 2017 17:16:14 -0700 Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Content-Transfer-Encoding: 7bit Message-Id: <C5A870C8-A7C7-4E84-AE88-AFFCC92299B1@dsl-only.net> References: <B7BEE165-C4AC-4670-9972-B9CB522A25DC@dsl-only.net> <7DB9F23E-2D55-44C3-AA91-C209BF584C4A@andric.com> To: Dimitry Andric <dimitry@andric.com> 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 <freebsd-toolchain.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>, <mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>; List-Post: <mailto:freebsd-toolchain@freebsd.org> List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>, <mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sat, 15 Apr 2017 00:16:24 -0000 On 2017-Apr-14, at 2:35 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 14 Apr 2017, at 22:40, Mark Millard <markmi at dsl-only.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.LNX.2.21.1704150928320.4604>