This bug shall serve as the root ancestor for all cross-compiling bugs. Any other bugs submitted to portage that relate to cross-compiling should be marked as blocking this bug. As such, this bug will never be closed, as there will likely always be ongoing problems being discovered. Instead, it should track the progress of the overall project history and provide a bigger picture description about related bugs. Here's are some examples to get us started. Aiken recently submitted bugs 18031 through 18034 which include ebuilds for the various toolchain components: *-headers, binutils, glibc, and gcc. These have been marked as dependecies of this bug (and thus this bug 'blocks' each of those bugs). These are the ebuilds that are currently being developed for eventual inclusion in the Portage tree. These ebuilds were developed through discussion on IRC and from all of the input we received via e-mail and other bugs. Notably, bugs 16740 and 17120 were influential in the advancement of the toolchain ebuilds. Related to these toolchain ebuilds is the script required to drive it. At present, there are two bugs with slightly different solutions to this problem. First, Aiken developed his own cross-gcc script (but 18789) that drives the series of emerges correctly, which I then used to integrate into the appropriate places in gcc-config (bug 18933). These are both still being developed at present time, but they can provide working cross-compiling toolchains in one step (if every thing Just Works). So, this then gives a small summary of the current cross-compiling state of affiars here in bugzilla, and all bugs discussed above have been marked as dependencies of this bug. I know there are numerous other changes to submit in order to allow many packages to be cross-compiled, and these will slowly appear linked to this bug as time goes on. I also found a few other bugs worth linking here that don't deserve special mention; however, I have tried to block this bug with every appropriately related issue. In the future, simply marking new bugs as blocking this one may be all that is required for simple issues, with occasional talk here to point out groups of related bugs or patterns emerging from the noise.
We recently have been conducting limited outside testing of these changes and now have several reports of success with the new --install-toolchain functionality. Numerous individuals are now successfully using these toolchains with distcc using heterogenous build pools, though many packages still need either their ebuilds or source updated. Because of these potentially widespread issues, we would like to see more people testing in order to expose these broken ebuilds/packages before we unleash this functionality on the masses. For example, portage itself manifests problems with distcc in mixed arch build pools. First, the ebuild uses 'gcc' explicitly instead of {CC:-gcc}, which is a perfect example of the changes recently suggested be made to the entire tree. While those fixes are trivial, the missingos python module setup script does not respect the CC env var, which seems to be a bug with python's distutils modules. Bug 20064 is now tracking these issues through to resolution, however, this makes me suspect that there may be related problems with other packages that want to install new python modules written in C; certainly, this should serve to raise our awareness about these issues. If nothing else, we have definitely developed a working proof-of-concept implementation of one-step cross-compiler installations. It should be able to play nicely with the rest of the system, and I think that having these changes in the main tree will be the best way for us to starting working to address its few known design deficiencies. For example, we need the ability for Portage to be able to install multiple instances of gcc (and other cross-compiling packages) in parallel with the native versions. Presently, we use a small hack to give each toolchain its own portage category, effectively making copies of the required package directories there via symlinks. As this obviously is not the best solution, bug 20071 is now tracking a proposal for Portage to detect CCHOST and use that as a key to "slot" the package orthagonally with already installed SLOT'd version(s). As this one change alone will probably require a database update, there are numerous related issues with cross-compiling that should also be considered; however, I think it would be unreasonable to delay inclusion of these features until this happens. Aiken and I will soon be attaching our "final" patches for bugs 18031-18034 and 18933. Stay tuned for those updates.
Is there a reason this is still open?
i see no reason to keep this open
