Dnia 2013-08-25, o godz. 23:55:59 Thomas Sachau <to...@gentoo.org> napisał(a):
> Michał Górny schrieb: > > Dnia 2013-08-25, o godz. 21:34:09 > > Thomas Sachau <to...@gentoo.org> napisał(a): > > > >> Ulrich Mueller schrieb: > >>>>>>>> On Sun, 25 Aug 2013, Thomas Sachau wrote: > >>> > >>>> workaround: add a variable, which changes the return of the function > >>>> checking for the current ABI (always true with variable, without > >>>> only true, when $ABI == $DEFAULT_ABI) > >>> > >>> Would this variable be set by the user, in profiles, or in ebuilds? > >> > >> This variable can be set by users and profiles, when they want binaries > >> for a different ABI (e.g. 64bit toolchain with 32bit userland). > > > > Where it simply won't work since executables for the native ABI will > > overwrite earlier ones. > > > > You obviously dont read my complete mails, otherwise you would have seen > my later example, which works perfectly fine, once this patch applied: > For the complete userland, set ABI_X86=32, so no 64bit target, no > executables for the native ABI, nothing overwriting the 32bit binaries > => it works. This is forbidden by profiles and as you noticed above would cause more screwup than benefit. > Of course, if there are further issues with the ebuilds (like only parts > of the dependencies converted with those needed for the binaries left > out), it may cause issues with the current situation of the eclass and > ebuild, but will again allow users of multilib-portage to do exactly, > what i described, since they already are able to build the dependencies > for their target ABI. :-) multilib-portage can set DEFAULT_ABI=$ABI as I suggested and you happily ignored. I can understand that this could cause issues but you didn't seem to care to reply. Instead, you are trying to mess up gx86 with more hacks for your fancy out-of-tree project. Hacks that will convince people something works while it doesn't. And didn't I write this already? -- Best regards, Michał Górny
signature.asc
Description: PGP signature
