Joshua Kinard: > On 06/16/2014 15:47, hasufell wrote: >> Jeroen Roovers: >>> On Mon, 16 Jun 2014 19:31:58 +0000 >>> hasufell <hasuf...@gentoo.org> wrote: >>> >>>> Also check the history of this thread for a few proposed solutions. >>> >>> The history of this thread and the history of gx86-multilib and >>> crossdev development suggest that crossdev was doing nothing wrong until >>> gx86-multilib came around and a problem was found between them. Masking >>> either for the benefit of the other would be, and let me quote the >>> history of this thread out of context just to fit in with the tone and >>> mode this sub-thread has taken, "asinine". >>> >> >> This isn't about right or wrong. This is about actual breakage on stable >> systems. >> >> Solutions were proposed, nothing has happened for months. >> >> So I don't see what else we can do here other than taking more radical >> steps to INFORM users of these possible breakages... and that's exactly >> what a hardmask is for. > > What about those of us who have been using crossdev to generate > cross-compilers for years w/o issue, because we run non-multilib? > Hardmasking crossdev to solve multilib problems doesn't accomplish anything, > other than just irk us. Why not hardmask the multilib stuff instead and > leave crossdev alone? >
Hardmask half of the tree instead of a single package? Does not sound reasonable. The fallout will be _huge_ for users who already run multilib. You will basically get an emerge dump of 500+ blockers. > > If so, is it sensible to allow crossdev to install a cross-toolchain when > the underlying machine architecture is the same, just a different ABI? > I.e., would a solution be to prevent i686-on-x86_64 or mips64-on-mips, but > still allow mips64-on-x86_64, and such? > That was already discussed and it will break: > yes, serving as a distcc server for x86 hosts or using 'cross emerge' > to build a x86 root from scratch
