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
papowell at astart.com
Mon Jun 26 14:10:44 UTC 2017
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
> 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
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
> 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
It is on my list to pursue directly afterwards, then.
(Luckily this only hits with most -CURRENT versions of FreeBSD and
older packages only.)
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
> /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.
> shows categories for builds for
> (Nothing for stable/*/ .)
> But the 10.3 rows show no package
> builds. I would guess that they
> start once 10.1 stops
> 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 at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
Patrick Powell Astart Technologies
papowell at 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
More information about the freebsd-stable