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