freebsd stable - Jun 2017 - 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

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 <markmi at 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-toolchain at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe at
freebsd.org"

Hi everyone,

I am testing a patch for gcc5-devel right now that will disable fixincludes (or
rather its fixed files) being packaged.

Should that work fine for you, I will push this back to gcc5 the following days.

That said, the change that triggered this is what I would expect on CURRENT, not
STABLE (and hence hoped we'd have more time for this change).

My Internet connectivity right now is only slightly above pigeon speed, so sorry
for any delays.

Gerald