Date: Sat, 24 Jun 2017 17:55:07 -0700 From: Mark Millard <markmi@dsl-only.net> To: re@FreeBSD.org, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD Ports <freebsd-ports@freebsd.org> Cc: Pedro Giffuni <pfg@FreeBSD.org>, Gerald Pfeifer <gerald@pfeifer.com> Subject: 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: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net>
next in thread | raw e-mail | index | archive | help
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.
>=20
> 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=3D%3Bamng&portname=3D=
gcc5&wildcard=3D
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.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6FD738D6-F163-4BC5-8E6E-A9B9F35595CD>