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

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

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