Summary: | portage binpkg reliance on CHOST metadata key should be on CTARGET | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Brian Harring (RETIRED) <ferringb> |
Component: | Binary packages support | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | truedfx |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.gentoo.org/proj/en/base/embedded/cross-development.xml | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Brian Harring (RETIRED)
2008-04-06 07:47:17 UTC
So, given your understanding of the meaning of CHOST and CTARGET, what's CBUILD? presumably you're fishing for something to whack me over the head with, so kindly just get to it instead of doing ping/ponging of msgs on bugzilla. Asking re: CBUILD is a bit daft considering it's in the url docs I'm quoting from, so I won't repeat it here. spb, what's your point here? In the case of binpkgs, what does CBUILD really matter when you're checking to make sure the binpkg matches the running system it's to be installed on? The meaning of CHOST implied in the original bug posting is, in fact, CBUILD. The meaning of CTARGET implied in the original message is, in fact, CHOST. The current behaviour of checking CHOST is correct. (In reply to comment #4) > The meaning of CHOST implied in the original bug posting is, in fact, CBUILD. > The meaning of CTARGET implied in the original message is, in fact, CHOST. The > current behaviour of checking CHOST is correct. Bit curious about your usage of 'original' there; seems like you're being rather specific for a reason (ie, there is an exemption somewhere). So... reason for 'original' (ie is there something here that needs correction), or is this bug INVALID (preferably with some extra confirmation since everyone seems to have slightly varying responses when questioned). Nice to see I got another lolgentoo entry out of this one, also. Okay, an attempt at a bit of an explanation of CBUILD/CHOST/CTARGET: > 1) I build a binpkg targeting ppc on x86. I can invalidly merge this package > on my x86. If you target ppc -- that is, if you build a ppc cross-compiler that itself runs on x86 -- you should be able to merge that on your x86, and not on your ppc. > 2) I build a binpkg targeting x86 on my ppc. I can't merge this pkg to my x86, > invalidly. If you target x86 -- that is, if you build a x86 cross-compiler that itself runs on ppc -- you should not be able to merge that on your x86, only on your ppc. CHOST is always the platform that the generated package runs on. Let's say you're building a cross-compiler for ppc on x86: the cross-compiler is being compiled on x86, will run on x86, and it will produce ppc objects. The package being built is the cross-compiler, which is built on and runs on x86, so it has an x86 CBUILD & CHOST. Now let's say you use that cross-compiler to build bash. Then, you have an x86 CBUILD, and a ppc CHOST, because bash is built on x86, but will run on ppc. The cross-compiler's CTARGET in the above is ppc. bash's CTARGET in the above is not used, since bash does not create anything that depends on it. Does this clear things up a bit? You wanted extra confirmation, you can check `info autoconf`, look in 13.1 (Manual configuration > Specifying names) for the description of --build, --host and --target. Grok; thank you for the confirmation (waxing the bug per my earlier comments). what needs to be done in the handbook ? i tried to flesh out these scenarios as it is confusing to many people who havent stared at it for people who dont eat this stuff every day. the main trouble is that the notion of build/host/target kind of shifts depending on what you're talking about. i tried to tackle this in the "Environment variables" table by covering the scenario of building a cross-compiler and then covering the scenario of cross-compiling something. these two cases (CBUILD==CHOST!=CTARGET and CBUILD!=CHOST==CTARGET) are by far the dominant combinations. (In reply to comment #8) > what needs to be done in the handbook ? i tried to flesh out these scenarios > as it is confusing to many people who havent stared at it for people who dont > eat this stuff every day. > > the main trouble is that the notion of build/host/target kind of shifts > depending on what you're talking about. i tried to tackle this in the > "Environment variables" table by covering the scenario of building a > cross-compiler and then covering the scenario of cross-compiling something. > these two cases (CBUILD==CHOST!=CTARGET and CBUILD!=CHOST==CTARGET) are by far > the dominant combinations. That I grok- personally, I'd probably remove the "meaning when building cross toolchain" and "meaning when building cross binaries"- just state instead that the toolchain itself is a special case. Dunno- don't really have any suggestions beyond that. ok, i can see that. most people wont be building a cross-compiler by hand, so having to know the combinations that soon will probably just be confusing. i'll document the cross-compiling case, and just relegate the cross-compiler case to a foot note. |