Date: Mon, 26 Jun 2017 07:00:45 -0700 From: Patrick Powell <papowell@astart.com> To: freebsd-ports@freebsd.org Cc: Gerald Pfeifer <gerald@pfeifer.com>, Dimitry Andric <dim@FreeBSD.org>, Konstantin Belousov <kostikbel@gmail.com>, freebsd-stable@freebsd.org, Jung-uk Kim <jkim@FreeBSD.org>, "papowell@astart.com" <papowell@astart.com>, Ian Cameron <icameron@digiwest.com> Subject: Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work Message-ID: <9b7cf494-1a81-4151-92fe-4a3305b17cb1@astart.com> In-Reply-To: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I have reported this problem - see email to freebsd-stable Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition Here is part of the discussion: 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 On 06/24/17 17:55, Mark Millard wrote: > The following is based mostly on an extraction from a > private exchange in which a question was asked and my > answer was unsettling: incompatibilities within the > 11.* family. I would not normally send to re but doing > so was explicitly mentioned. Hopefully this example is > reasonable for doing that. > > > Aspect #0: what is broken currently (and in the future?) > within the 11.* family? > > lang/gcc* packages built on release/11.0.1/ to not work > fully on stable/11/ or on the drafts of > release/11.1.0/ . (I leave releng/11.*/'s implicit.) > > -r313194 in head and was describied with: > >> Define the vm_ooffset_t and vm_pindex_t types as machine-independend. >> >> 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. > The known issue is the generation of header dependencies > in the lang/gcc* builds on release/11.0.1/ that when > used on stable/11/ or release/11.0.1/ generate reports > like: > > /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys/types.h:266:9: error: '__vm_ooffset_t' does not name a type > typedef __vm_ooffset_t vm_ooffset_t; > ^ > /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys/types.h:268:9: error: '__vm_pindex_t' does not name a type > typedef __vm_pindex_t vm_pindex_t; > ^ > *** [CoinFactorization2.lo] Error code 1 > > Unfortunately UPDATING was not updated > for head/'s -r313194 (2017-Feb-4) --nor for > stable/11/'s -r313574 (2017-Feb-11), the MFC. > (No MFC was made to stable/10/ or to > release/10.3.0 as far as I found.) > > (These changes predate the INO64 issue in head/ . > Head ends up with more issues than I'm dealing > with here.) > > > Aspect #1: what 11.* version builds the pre-built packages > targeting 11.* and the apparent consequences > (given the vm_ooffset_t and vm_pindex_t changes > and the lang/gcc* build behavior) > > This is the unsettling part for pre-built > packages: incompatibilities within the 11.* > family for the lang/gcc* packages. > > http://portsmon.freebsd.org/portoverview.py?category=%3Bamng&portname=gcc5&wildcard= > > shows categories for builds for > > 8.4 > 9.3 > 10.1 > 10.3 > 11.0 > head > > (Nothing for stable/*/ .) > > But the 10.3 rows show no package > builds. I would guess that they > start once 10.1 stops > (approximately). > > So it may be that 11.1 will not > get package builds until 11.0 > stops (approximately). > > If so unless lang/gcc* are changed > to bootstrap differently they will > configure to match release/11.0.1/ > and will not be compatible with the > vm_ooffset_t and vm_pindex_t changes > in stable/11/ and release/11.1.0/ . > > But as I understand updating how the > lang/gcc* builds work to remove such > dependencies is under investigation. > I do not know any timing relative to > release/11.1.0/ if my understanding > is right. > > Until then (if I was right): > > Unless there are separate packages made for > targeting release/11.0.1/ vs. release/11.1.0/ > it is not obvious when lang/gcc* packages > will be generally compatible with various > folks choices about what to install as the > system version within the release/11.*/ > and stable/11/ family. This would likely > be true even if they were built on > release/11.1.0/ : then release/11.0.1/ > likely would have compatibility problems. > > The ABI versioning does not cover the specific > issues involved based on how vm_ooffset_t and > vm_pindex_t were changed and what the > lang/gcc* builds do relative to such changes. > Yet there is incompatibility for some > fairly-significant-usage ports. > > > Aspect #2: stable/10/ and release/10.4.0/ > > Just covered for completeness: > > I do not see a MFC of -r313194 to stable/10/ : > its sys/sys/types.h dates back to 2015-Oct-10. > So it looks like 10.x has a permanent difference > in this area: 10.x continues to get separate > lang/gcc* package builds from 11.x and later. > No problem for this context as far as I know. > > > > > Note: To simplify I choose to not be explicit > about what authors wrote what original text. > If that becomes an issue, it is correctable. > > Blame me for any errors in the above. > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > -- Patrick Powell Astart Technologies papowell@astart.com 1530 Jamacha Rd, Suite X Network and System San Diego, CA 92019 Consulting Cell 858-518-7581 FAX 858-751-2435 Web: papowell at astart dot com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9b7cf494-1a81-4151-92fe-4a3305b17cb1>