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

Patrick Powell papowell at
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
>> 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 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
> 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.

(  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.)


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.
> 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
> _______________________________________________
> freebsd-ports at mailing list
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at"

Patrick Powell                 Astart Technologies
papowell at            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 mailing list