1 |
On Fri, Mar 19, 2004 at 04:15:56AM +0100, Pieter Van den Abeele wrote: |
2 |
> Hi, |
3 |
> |
4 |
> I have a few remarks about the 2004.1 feature list. My incentive for |
5 |
> making these remarks is to get an idea how/when to schedule time for |
6 |
> testing/implementing each feature, and to signal some of the problems |
7 |
> we could be confronted relatively well in advance. |
8 |
> |
9 |
|
10 |
I've been working on some of this stuff so I'll take a stab at noting |
11 |
what I know of the situation. I'm not a dev, but I'm a guy who's |
12 |
trying to commit code. It may help for you to read my email on |
13 |
enhancements for catalyst I proposed last month(posted to releng and embedded). |
14 |
|
15 |
> |
16 |
> 1. What is the scope of catalyst cross-compilation integration? |
17 |
> |
18 |
> Daniel said in his stanford presentation that there is |
19 |
> cross-compilation and "true" cross-compilation. Which of those is meant |
20 |
> to be integrated into catalyst? |
21 |
> |
22 |
> It should be clear that true cross compilation is difficult to achieve |
23 |
> for stage and GRP building. Consider for instance the case where |
24 |
> somebody on intel architecture wants to build powerpc stages. We know |
25 |
> that it is impossible to take a ppc stage on an intel machine and |
26 |
> chroot into it, because the intel microprocessor can't run ppc |
27 |
> micro-instructions. What would be possible is to take an x86 stage, |
28 |
> install a cross compilation toolchain into it and use that toolchain to |
29 |
> cross compile an application. |
30 |
|
31 |
Really it isn't that hard. You just don't get to test whether |
32 |
everything works until AFTER you've finished building everything. |
33 |
|
34 |
Just to note I define cross systems as a native tools producing |
35 |
non-native output. This could be non-native architechture or |
36 |
non-native libc or non-native system linkings(ex: BSD vs. linux). So |
37 |
we really are talking about MORE than just ppc's compiling intel |
38 |
stages. |
39 |
|
40 |
> How bootstrapping/dependencies would be |
41 |
> handled is something that should be thought about. Are there any |
42 |
> ebuilds alternative architectures could start looking at regarding |
43 |
> cross-compilation toolchains? Or will the implementors of these |
44 |
|
45 |
In regards for catalyst I was hoping to have an alternate type of |
46 |
stage from the native stage[1,2,3]. A cross-stage[1,2,3] which is |
47 |
used to produce the native stages. for example: |
48 |
|
49 |
native arch X needs to produce a stage for non-native arch Y. |
50 |
|
51 |
1) stage[1,2,3] for arch X are built/aquired |
52 |
2) catalyst uses the previous stage to produce a cross-stage[1,2] for |
53 |
arch Y |
54 |
3) catalyst uses the cross-stage to produce non-native arch Y stage[1,2,3] |
55 |
|
56 |
> toolchains mask cross-compilation toolchains stable for the affected |
57 |
> target alternative architectures, assuming the cross-compiled results |
58 |
> work as expected on the target architecture? If true cross compilation |
59 |
> is really on the agenda, what will it's impact be on the current |
60 |
> catalyst targets' behaviour, I take it we'll have to work around the |
61 |
> chroot limitation? |
62 |
|
63 |
you just don't chroot, simple as that ;-) Everything is merged with |
64 |
$ROOT set to a directory inside the cross-stage. Build everything so |
65 |
it is merged into that directory. The only problem is some ebuilds |
66 |
don't behave properly. Example: |
67 |
|
68 |
1) ebuild foo needs to check for library bar(this check isn't in the |
69 |
configure script, don't ask me why this is just what I've observed) |
70 |
2) $ROOT contains library bar, but / does not contain library bar |
71 |
3) ebuild foo does the check and FAILS because bar does not appear to |
72 |
be in the place it's looking for it |
73 |
|
74 |
This is just one example, I'm sure there are others. What I want to |
75 |
illustrate is that gentoo wasn't necessarily deisgned to deal with all |
76 |
this abstraction for non-native creation of binaries. That's chaning |
77 |
with Kumba's cross-dev scripts and dragonheart's uclibc toolchain but |
78 |
there is a bit of work ahead. |
79 |
|
80 |
> When should alternative architectures start testing |
81 |
> results produced by the catalyst cross compilation process, or will the |
82 |
> feature be alpha quality on release? |
83 |
> |
84 |
|
85 |
This isn't an issue I can comment on. ;-) |
86 |
|
87 |
> Isn't the non-true cross-compilation, (where the host can run the |
88 |
> targets microinstructions) trivial? I can already use my 64bit G5 to |
89 |
> build regular ppc, G3 and G4 stages because the G5 can run G4,G3 and |
90 |
> ppc instructions, on both a 32bit and 64bit kernel. |
91 |
> My question to releng regarding non-true cross-compilation is the |
92 |
> following: What changes can we expect to catalyst? I guess some kind of |
93 |
> checking mechanism will be implemented/activated? Should we really call |
94 |
> it cross-compilation in our marketing talk? |
95 |
> |
96 |
|
97 |
IMHO the distinction is only relevent by when deciding whether to use |
98 |
these cross-stages or not. My understanding of the 32-bit/64-bit |
99 |
compilation methods is that you need only enable multilib with gcc and |
100 |
link with the proper libraries. Not sure whether this requires a |
101 |
whole staged cross-toolchain or whether the toolchain present on the |
102 |
users system can be used for this. These types of things need to be |
103 |
defined(although I should note there is some desire for people to be |
104 |
able to use their cross-toolchains already on the system instead of |
105 |
packaged staged ones) |
106 |
|
107 |
-- |
108 |
gentoo-releng@g.o mailing list |