From owner-freebsd-stable@freebsd.org Sun Apr 30 15:20:35 2017 Return-Path: Delivered-To: freebsd-stable@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 6C556D57249 for ; Sun, 30 Apr 2017 15:20:35 +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 37E2CDAB; Sun, 30 Apr 2017 15:20:34 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from anthias (vie-188-118-250-006.dsl.sil.at [188.118.250.6]) (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 DCC2A3F53E; Sun, 30 Apr 2017 11:20:31 -0400 (EDT) Date: Sun, 30 Apr 2017 17:20:27 +0200 (CEST) From: Gerald Pfeifer To: Dimitry Andric , Konstantin Belousov cc: Jung-uk Kim , freebsd-stable@freebsd.org, papowell@astart.com Subject: Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition In-Reply-To: <1AB1479F-EB72-4D8C-8112-E7C63D3AC07A@FreeBSD.org> Message-ID: References: <8316fd8e-056d-32a1-1e59-414269476190@astart.com> <95c6f08e-0cf7-f0f3-8b19-29e03b3f4f96@FreeBSD.org> <39149f1c-d939-5c60-a0c3-ab76fa0f750b@astart.com> <22bfc9eb-f037-cb1e-931f-a995e98093e2@FreeBSD.org> <163343D9-0396-4468-B666-DD9D8AEE176B@FreeBSD.org> <20170430120626.GT1622@kib.kiev.ua> <1AB1479F-EB72-4D8C-8112-E7C63D3AC07A@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 15:20:35 -0000 On Sat, 29 Apr 2017, Dimitry Andric wrote: > This is because gcc's fixincludes process makes copies of certain system > headers (in this case, /usr/include/sys/types.h) with slight > modifications. Then, it places the directory containing the modified > headers at the front of the include search path. So far so good. > > Now, whenever sys/types.h is updated, as happened with the vm_ooffset_t > change, the header in gcc's own preferred directory might not match the > definitions which are expected, leading to compilation errors. >> If the port/package is builts from scratch, does this trigger the >> problem? > Yes, basically you need to rebuild all gcc ports from scratch, whenever > you update any system header that matches gcc's list of files it wants > to modify. That, or run the fixinc.sh script in ./libexec/gcc/$TARGETTRIPLET/$VERSION/install-tools/fixinc.sh. The proposed patch would help with that, but still require a manual run, hence my original question. On Sun, 30 Apr 2017, Konstantin Belousov wrote: > Am I right that Jung-uk fix replaces vm_ooffset_t and vm_pindex_t with > explicit int64_t and uint64_t use, as the course of action for gcc > fixincludes step ? If yes, I completely disagree. > > The change blocks any future changes to the type that might occur in the > base system, for the code compiled by gcc. End result might be as bad > as mismatched ABI, in the worst case. Okay, thanks for your feedback. > With all of the above, IMO most sane way to fix problems is to > rename fixincludes directory to some name which is ignored by gcc, > e.g. include-fixed -> include-fixed.saved. This can be done as > post-installation step in the ports. This is what I figured, too, and plan on giving a try. It probably warrants an -exp run to be on the safe side. On Sun, 30 Apr 2017, Dimitry Andric wrote: > I agree, it would be best to avoid storing any copies of system headers > completely. > > Maybe the port can have an option FIX_INCLUDES, which defaults to off? > I am not sure if there is anybody that really wants these 'fixed' > headers, though. :) There are two infrastructure improvements for the (current) GCC ports (orthogonal to a few simpler things I've been simplifying today in older ports) that I'd like to conclude first, otherwise there'll be too many balls in the air. ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218475 is the last hold-off on the first of them, in case anyone can give this a try. ;-) It is on my list to pursue directly afterwards, then. (Luckily this only hits with most -CURRENT versions of FreeBSD and older packages only.) Gerald