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

Mark Millard markmi at
Sun Jun 25 00:55:11 UTC 2017

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

More information about the freebsd-ports mailing list