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

[Gerald Pfeifer]

Am 28. Juni 2017 22:38:52 GMT+08:00 schrieb Mark Millard <markmi at dsl-only.net>:
>A primary test is building lang/gcc5-devel under release/11.0.1
>and then using it under stable/11 or some draft of release/11.1.0 .

Thank you, Mark. Let me know how it went. In the meantime I'll prepare the change for gcc5 itself.

>It looks like the the lang/gcc5-devel build still creates and
>uses the headers that go in include-fixed/ but that they are
>removed from $(STAGEDIR}${TARGLIB} 's tree before installation
>or packaging.
>
>So, if I understand right, lang/gcc5-devel itself still does use
>the adjusted headers to produce its own materials but when
>lang/gcc5-devel is used later it does not. Definitely
>something to be testing since it is a mix overall.

I am not worried about that since that should not cause any binary incompatibilities (ABI). The problem we encountered was about source code and API in a wide sense of that term.

>Is some form of exp-like run needed that tries to force use
>of a release/11.0.1 built lang/gcc5-devel (-r444563) to build
>other things under, say, stable/11  or some draft of
>release/11.1.0 ? Is this odd combination even possible
>currently?

I am not aware of it, and while originally I was thinking to request an -exp run (after the GCC version update which is dragging due to broken ports), time is not on our side and the change should be low risk.

> [altermative approach] But I guess that did not work out.

Not with my current level of connectivity and my notebook a dead brick on top of that. And my preference is to still build, but stow away (unless explicitly requested to keep).

>Eventually most of the lang/gcc* 's will need whatever
>technique is used.

Yes, agreed. Version 5 is most important since it's the default; then 6; 4.x is for retro computing fans ;-), so 7 will then be next.

Gerald