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

[Mark Millard]

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