Summary: | Cross-compiling meta-bug history | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Zach Welch (RETIRED) <zwelch> |
Component: | [OLD] Development | Assignee: | Lisa Seelye (RETIRED) <lisa> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | aiken, azarah, beta, trapni |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 16740, 17120, 18031, 18032, 18033, 18034, 18789, 18818, 18933, 20064, 20071 | ||
Bug Blocks: |
Description
Zach Welch (RETIRED)
2003-04-07 19:17:00 UTC
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 |