Top post on one point. . .
Patrick Powell papowell at astart.com wrote on Mon Jun 26 14:10:44 UTC 2017
(He was quoting Gerald. I was also part of some earlier discussions.)
> (Luckily this only hits with most -CURRENT versions of FreeBSD and
> older packages only.)
>
> Gerald
Unfortunately this part is false if it is about the vm_ooffset_t
and vm_pindex_t issue: stable/11/ and release/11.1.0/ also
have the vm_ooffset_t and vm_pindex_t issue vs. lang/gcc*
packages built by release/11.0.1/ .
The issue is not limited to head (12) at this point:
Installing a gcc* package built by release/11.0.1/ fails
now for stable/11/ and the drafs oft release/11.1.0/ .
Anyone progressing to one of those has to build the
lang/gcc* of interest from source under the newer system
context. (Mixing source builds and package builds is
discouraged as I understand.)
I'm not claiming which specific handling needs to be made.
But the vm_ooffset_t and vm_pindex_t changes did not even
make the UPDATING notes. Right now things look to have
the worst combination for lang/gcc* when release/11.1.0/
becomes official: lang/gcc* 's break without notification
or suggestion of a workaround.
===
Mark Millard
markmi at dsl-only.net
On 2017-Jun-24, at 5:55 PM, Mark Millard <mar...@dsl-only.net> 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-toolch...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
