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

On 2017-Jun-28, at 3:21 AM, Gerald Pfeifer <gerald at pfeifer.com> wrote:
> 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.

Thanks!

Some notes:

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 .

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.

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?

A normal exp-run on release/11.0.1 without a system version
switch being involved also seems appropriate. The same could
be said of an exp-run based on a release/11.1.0 draft for
both building lang/gcc5-devel and using it to build other
things.



I had hoped that the Linux From Scratch technique of doing:

sed -i 's@\./fixinc\.sh at -c true@' gcc/Makefile.in

(or an equivalent) before gcc/Makefile.in is used would
allow lang/gcc5-devel to use the same headers in its build
that the installed compiler would then use to produce other
code --by avoiding generating most of the adjusted files in
the first place. But I guess that did not work out.

Eventually most of the lang/gcc* 's will need whatever
technique is used. Some, such as lang/gcc6-aux, need
more done because of binary bootstrap materials being
downloaded and used and so the build of lang/gcc6-aux
gets the problem and fails before staging happens: the
binary-bootstrap materials need to avoid the adjusted
headers that they currently contain.

==Mark Millard
markmi at dsl-only.net

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