Post
by plewright » Mon May 30, 2005 9:30 am
I understand what you mean, that the I2C is one of the hardware modules suddenly without its hardware, so would normally spit the dummy when it finds itself as a ghost having been ripped from its body, I would spit the dummy too if some higher being separated my body from my head. Spitting the dummy would be about all I could do wouldn't it? At least I would still have a mouth, to use! Just like an I2C module complaining to the terminal. Somehow that draws my thoughts to Hitch Hiker's Guide to the Galaxy!?
So when its spitting the dummy, are you saying that it's NOT related to the "Build Environment"? Is it just a coincidince that it comes up then at the same time? Or is there more to this baby?
The thing that I am worried about, stemming from not having dealt much with the Build Environment, which is used by Magic and Portage. After "mounting" and "chrooting", do the "env-update" and "source profile" commands mentioned by Orpheus, do they accomplish EVERYTHING that is required? Are ALL possible settings for the build environment IDENTICAL under the CoLinux Kernal and PC hardware, as they are on the Gentoox kernal and XBox hardware?
Is there anything used by the build environment that might be different?
Can we trust that the given "profile" covers everything, especially if we are intentionally doing the opposite of what it's meant for, by purposely running it on a different hardware and with a different Kernal? Does Magic/Portage/Emerge look at the profile only???
For example, on my P4, HypedupThreading is noticed when CoLinux starts up, as it outputs "multi-threading" stuff to the screen during start-up. I don't know if this information is found in the same place as for example the "uname" command which tells me that it's a 686 under Gentoo. I havn't yet checked what "uname" reports under the Gentoox rootfs running from the CoLinux kernal because that wouldn't really answer my question because I dont know if that is the same place that the build environement finds what CPU is being used. For all I know, the build process potentially "probes" for info "outside" for info that isn't covered in the "profile."
Continuing with this example scenario, now what happens when the "Magic" system downloads a package that could make use of the multi-threading, e.g. as some compression programs do? Does it mistakingly include it into the package when building it, because it automatically probes and finds a multi-threading CPU, only to consequently crash when later run on my Xbox? Or does it not look passed a certain point, because it is completely 100% restricted within the pre-definded boundary when "env-update" and "source profile" are called?
My current (lack of) understanding limits me to expect one of two answers: either, a, b (or c),
a) DIFFERENT: the build environment could be different, because of x,y,z (cool if you could point me to where to start looking for the list of settings, probings etc.) Perhaps someone could offer some experience or examples that would at least let me know then that I have to spend time learning all about the Build Environment vs the Profile to be 100% satisfied.
b) SAME: the build environment is the same, because ALL POSSIBLE settings are defined in the "Profile", given inside the rootfs, which CAN NOT change automatically. If this is true however, then how does the Profile completely restrict the range of variables that might not have even been thought of, when new packages are developed?
Following from my example above, unfortunately it is most likely covered, but just for the analogy because there are bound to be extra/new features that are created for new Profiles that couldn't possibly be covered by existing profiles. So, given that the zipping Package was prepared with the option to utilise the hyperthreading to be included during the build process, then imagine that the corresponding variable was not defined or even thought of when the Gentoox profile was made, say something like the variable MULTITHRD (I don't know what the real variable name is, or if there is one), but say that is what is looked for in the Profile. So what does the Magic/Emerge/Portage system after not finding in the Profile the value? Does it then try to probe outside, and find out for itself what CPU it there? Or, how does it choose weather or not to use that feature?
One solution I imagine (but have no clue about "Profiles", so don't quote me) is that the potential package must have some sort of interface, that the host Magic/Emerge/Portage system looks at, which defines the complete list of all of the features that it would need to use in the host's Profile when building. The host system could compare its own list of variables and ensure that there are not any unknown ones that the potential package would be looking for. Note also, that users can change/tweak their own build "Profile" so the package system couldn't easily rely on using a controlled pre-defined simple set of expected "Profiles." Unfortunaltey, every single element of the profile would need to be checked, but only then would it be possible to cover everything, ensuring 100% compatibility, and the only way I can think of that ensures there is no need for a package to look beyond the Profile.
c) ANOTHER TOPIC? Has this been covered? Is their somewhere else a discussion of the internals and workings of Magic? and Xbox Profile? Or does this thread continue and follow through, because however much benefit using a faster PC to compile appears to be, moving the build environment to another (different) one raises concerns. (for us yet to be educated anyway.)
I should apologise for the repeatedness of the question presented here, but I reckon this time it might be more clear as to what I was looking for, than from my earlier post.
Christopher
