(impl) lsbsi conculsions
I had a question today about phase4 build items
that require build support that is not present
in phase2, which is the "build environment" for
both phases 3 and 4.
It was not felt safe to just add them to phase 2,
since configure scripts being what they are,
there's a risk something destined for the lsbsi
(phase 3) might pick up something it should not.
I think this risk can be managed, but not to
do it was the sense of the call.
The phase 4 build could simply build the items
in question and do "make install" instead of
the normal "make install prefix=/mnt/blahblah",
which would stick them in on top of phase 2,
but after it was used to complete phase 3.
This harms restartability/reproducibility:
it's hard to see an lsbsi-intermediate and know
what state it's in.
The suggestion from the call was to duplicate
the logic used by phase2, which copies lsbsi-bootstrap
and then builds on top of the copy to make
lsbsi-intermediate. This seems a bit of a pain
given that it's 400 meg on an ia32 platform,
but I can go down that path if that's what we want.
(Sigh). Quick - somebody talk me out of it
before I get started.
==================================================
Another topic that needs resolution is that while
the scheme seeks a cleanroom build by bootstrapping
itself, there's at least one known outside interaction:
the gcc build does fixincludes, which pulls in things
from the native environment. We found at least one
place where newer glibc code, if running on a host,
is not compatible with the released 2.2.5 glibc in the
lsbsi, in a way that is exposed by this build scheme.
One possibility to investigate is to try to convince
the gcc build for lsbsi-bootstrap that it's a cross
compiler, since in this case it might avoid pulling
in things from the host.
==================================================
The third issue, discussed in email, but not during
the call, is that some further work is needed by
the conditional element in the nALFS tool, possibly
to change to this style:
<cond type="arch">
<case value="ia32">
</case>
<case value="ia64">
</case>
<default>
</default>
</cond>
where the processor type is a value, not a tag in
and of itself.
===================================================
Reply to: