The lastest improvements to gcc-config (see bug 18933) rely on a CATEGORY hack to allow the cross-compiling toolchains to be installed in parallel with the native toolchain. Instead, Portage should detect the fact that CCHOST is being used and "slot" the package orthagonally in its database. In other words, a "parallel universe" of packages should exist if CCHOST is used, though only a handful of ebuilds will need to use this initially; however, cross-compiling requires that libraries needed for link be installed locally (under /usr/${CCHOST}/{lib,include}). This will require that all such libraries ebuilds support cross-targeting installs like this; that raises different issues but should underscore the need for this generalized facility. We had also considered changing SLOT to "${MY_PV}-${CCHOST}"; however, that probably breaks the portage cache completely. As such, I think the above proposal is the "best" solution, even if it must wait for a database overhaul. In the meantime, the CATEGORY hack does work well enough for bleeding edge users to cut their teeth with cross-compilers.
In one sentence: We need portage to be able to support multiple SLOTs for the same version of the package. This has been discussed in the past, but and the need has been confirmed. I think even somebody was working on it, but it really is getting critical now.
Err, just to clarify, multi SLOT per version is what is needed ... the addition of the CCHOST is just needed if depcache cannot be fixed to handle the changing of SLOT depending on CCHOST, IMHO of course.
Certainly, my point here iss not to dictate the implementation; however, I can not see how SLOT could be cached at all if we introduce the following idiom: [ "${CHOST}" = "${CCHOST}" ] && \ SLOT="${MY_PV}" || \ SLOT="${MY_PV}-${CCHOST}" In order to cache that, you would need to know all possible values of CCHOST, which is itself a potentially infinite set. For example, 'i686-zwelch-linux-gnu' is a perfectly legitimate CHOST name. Honestly, I can not see how the SLOT solution will work effectively, though disabling depcache if CCHOST is set would be an ugly but functional kludge. In fact, portage should generate parallel depcaches for each CCHOST (as it learns about them through usage), as the dependencies need to be filled with CCHOST set (which will install the files in different locations that if not). In addition, this would allow each CCHOST to be used to determine DEPEND, PROVIDE, HOMEPAGE, SRC_URI and other cached variables. This also begins to touch on the need for generalized functionality to support the prolific number of ARM machine types, and for the embedded world in general. If each machine could be given its own identifier (e.g. armv4l-netwider-linux-gnu, armv4l-ipaq-linux-gnu, etc.) and portage could be taught to create a unique depcache for every CHOST is encounters, this facility could also be used to provide per-machine patches and homepages in arm-headers and arm-sources. Otherwise, I foresee an unavoidable proliferation of otherwise identical ebuilds for each new platform. So to clarify, this bug really is about creating parallel depcaches for each CHOST in order to allow CCHOST versions of packages to be installed in parallel on the machine, as well as allowing the most flexibility for ebuild writers to support cross-compiling without the depcache getting in the way. Thoughts?
Just to further clarify, there is no visible difference between CHOST and CCHOST; while they have different functions, their values are potentially interchangable. I try to refer to CCHOST in the context of building toolchains and CHOST in the context of cross-compiling with those toolchains. As alluded to in my last comment, this proposal is meant to be applied to both situations. Sorry for any confusion.
Problem is that this is not limited to cross compiling. Think of nvidia-kernel for instance .... there SLOT="$KV".
Zach mentioned "cross-compiling requires that libraries needed for link be installed locally (under /usr/${CCHOST}/{lib,include})" In the past this is what I have done but it requires compiling the library in question twice. Once to put it under /usr/$CCHOST and the second time to put in $ROOT. I have modifed a few ebuilds to play with cross compiling small environments. First I cross compile glibc and ncurses and put them in ROOT(/tmp/cross-sparc). Bash will fail because it can not find ncurses. As Zach said it will look for the lib in /usr/$CCHOST/{lib/include}. To get around this I changed my copy of the bash ebuild such that if it is being cross compiled add "-I${ROOT}/usr/include -L${ROOT}/lib -L${ROOT}/usr/lib" to CFLAGS. The cross compiler can now find the appropriate includes and libs. Not all packages need this. At the moment it comes under the heading of 'This is what I have done and so far works for me. Another problem is the storage of tbz2 files. If buildpkg is set in FEATURES even when cross compiling the packages get put in the same place. My /usr/portage/pakages/ALL currently has packages of mixed CHOST (x86, sparc and arm). If I emerge binutils then ROOT=/tmp/delme CHOST=sparc-sun4c-linux-gnu emerge binutils both will create a binary package but the second emerge will over write the native tbz2 from the 1st emerge. The command emerge -k binutils then becames very dangerous. It would be a lot safer if portage could put tbz2 files for different arch in separate directories.
I am not arguing that we do not need special attention for CCHOST, but what I am saying, is: The start should be to support multiple SLOT for one version of a package, because it is needed by more than ebuilds that touch CCHOST. We should do it the right way from day one. Can anybody remember who was supposed to work on the multi-SLOT per version issue ?
Here's a novel suggestion: SLOT="${PV}.$(slothash ${CCHOST})" where `slothash' is a function to convert a string into a version string. The only question then is what limitations portage has in its version checking code. For example, a CRC32 broken into N digit tuples would provide a 'signature' version suffix that would probably get us around the current limitations. Incidently, we're currently wrapping such SLOT tricks in crosscompile.eclass, in the cross-setslot function. I'll be checking in a new version shortly that has some minor changes to that function, though I haven't quite yet figured out how to implement this hack in a small bash function. In the future when Portage supports such, this function can stop using the hash function and directly set an alphanumeric SLOT. As such, our working ebuilds simply call 'cross-setslot "${MY_PV}"' and the above cross-slotting magic happens transparently. Only the toolchain ebuilds need this treatment, though others ebuilds could perhaps leverage it too. I hate suggesting such an obvious hack, but I want to see this functionality reach the tree sooner rather than later.
Multiple slots for the same version of packages still doesn't work. This is necessary, as has already been mentioned, for packages such as nvidia-kernel. For those who want to see how this problem manifests itself, here's how reproduce it: 1) You have a machine with two sets of kernel sources in /usr/src, call them "sources1" and "sources2". 2) Symlink /usr/src/linux to look at sources1. Then emerge say, =nvidia-kernel-1.0.4496-r4. SLOT for this package will be set to ${KV} for sources1, and the nvidia.o module will be installed in /lib/modules/${KV} (where ${KV} is taken from the first line of /usr/src/linux/include/linux/version.h). 3) Now change the /usr/src/linux symlink to point to sources2. emerge again, and although SLOT for the package will be changed to ${KV} for sources2, the old package will be unmerged and you'll lose the nvidia.o installed at stage 2). Expected behaivour: portage would hangle and check SLOTs for the package. I really hope someone is working on this. The obvious problem I can think of is that the "/var/db/category/packagename-version" database can't obviously handle multiple copies of the same package version. It may be possible to have that single directory track both copies of the package... multi-line ./SLOT file, ./USE file etc.? With a new kernel just hitting stable, this problem is going to annoy a lot of people who from necessity switch between 2.4 and 2.6 kernels, like me. :-)
This bug could do with a better name - or perhaps a new bug should be created.
This is LATER ( 2.1.x? ). I believe ferringb is considering X-compile support in HEAD regarding build profiles/domains and would take care of this issue.
