Re: [gentoo-releng] 2004.1 feature list questions

On Fri, Mar 19, 2004 at 04:15:56AM +0100, Pieter Van den Abeele wrote:
> Hi,
>
> I have a few remarks about the 2004.1 feature list. My incentive for
> making these remarks is to get an idea how/when to schedule time for
> testing/implementing each feature, and to signal some of the problems
> we could be confronted relatively well in advance.
>

I've been working on some of this stuff so I'll take a stab at noting
what I know of the situation.  I'm not a dev, but I'm a guy who's
trying to commit code.  It may help for you to read my email on
enhancements for catalyst I proposed last month(posted to releng and embedded).

>
> 1. What is the scope of catalyst cross-compilation integration?
>
> Daniel said in his stanford presentation that there is
> cross-compilation and "true" cross-compilation. Which of those is meant
> to be integrated into catalyst?
>
> It should be clear that true cross compilation is difficult to achieve
> for stage and GRP building. Consider for instance the case where
> somebody on intel architecture wants to build powerpc stages. We know
> that it is impossible to take a ppc stage on an intel machine and
> chroot into it, because the intel microprocessor can't run ppc
> micro-instructions. What would be possible is to take an x86 stage,
> install a cross compilation toolchain into it and use that toolchain to
> cross compile an application.

Really it isn't that hard.  You just don't get to test whether
everything works until AFTER you've finished building everything.

Just to note I define cross systems as a native tools producing 
non-native output.  This could be non-native architechture or
non-native libc or non-native system linkings(ex: BSD vs. linux).  So
we really are talking about MORE than just ppc's compiling intel
stages.

> How bootstrapping/dependencies would be
> handled is something that should be thought about. Are there any
> ebuilds alternative architectures could start looking at regarding
> cross-compilation toolchains? Or will the implementors of these

In regards for catalyst I was hoping to have an alternate type of
stage from the native stage[1,2,3].  A cross-stage[1,2,3] which is
used to produce the native stages.  for example:

native arch X needs to produce a stage for non-native arch Y.

1) stage[1,2,3] for arch X are built/aquired
2) catalyst uses the previous stage to produce a cross-stage[1,2] for
arch Y
3) catalyst uses the cross-stage to produce non-native arch Y stage[1,2,3]

> toolchains mask cross-compilation toolchains stable for the affected
> target alternative architectures, assuming the cross-compiled results
> work as expected on the target architecture? If true cross compilation
> is really on the agenda, what will it's impact be on the current
> catalyst targets' behaviour, I take it we'll have to work around the
> chroot limitation?

you just don't chroot, simple as that ;-) Everything is merged with
$ROOT set to a directory inside the cross-stage.  Build everything so
it is merged into that directory.  The only problem is some ebuilds
don't behave properly.  Example:

1) ebuild foo needs to check for library bar(this check isn't in the
configure script, don't ask me why this is just what I've observed)
2) $ROOT contains library bar, but / does not contain library bar
3) ebuild foo does the check and FAILS because bar does not appear to
be in the place it's looking for it

This is just one example, I'm sure there are others.  What I want to
illustrate is that gentoo wasn't necessarily deisgned to deal with all
this abstraction for non-native creation of binaries.  That's chaning
with Kumba's cross-dev scripts and dragonheart's uclibc toolchain but
there is a bit of work ahead.

> When should alternative architectures start testing
> results produced by the catalyst cross compilation process, or will the
> feature be alpha quality on release?
>

This isn't an issue I can comment on.  ;-)

> Isn't the non-true cross-compilation, (where the host can run the
> targets microinstructions) trivial? I can already use my 64bit G5 to
> build regular ppc, G3 and G4 stages because the G5 can run G4,G3 and
> ppc instructions, on both a 32bit and 64bit kernel.
> My question to releng regarding non-true cross-compilation is the
> following: What changes can we expect to catalyst? I guess some kind of
> checking mechanism will be implemented/activated? Should we really call
> it cross-compilation in our marketing talk?
>

IMHO the distinction is only relevent by when deciding whether to use
these cross-stages or not.  My understanding of the 32-bit/64-bit
compilation methods is that you need only enable multilib with gcc and
link with the proper libraries.  Not sure whether this requires a
whole staged cross-toolchain or whether the toolchain present on the
users system can be used for this.  These types of things need to be
defined(although I should note there is some desire for people to be
able to use their cross-toolchains already on the system instead of
packaged staged ones)

--
gentoo-releng@g.o mailing list