On Mon, Jul 29, 2013 at 9:50 PM, David Starner <prosfil...@gmail.com> wrote: > Sorry about the blank message; I accidentally hit the wrong button. > > On Mon, Jul 29, 2013 at 7:19 AM, Andrew Haley <a...@redhat.com> wrote: >> It was "This is possible, but it's tricky, and it's really important >> to get it right. We don't want a half-arsed patch." > > We've all seen cases where a quick patch is rejected in favor of a > hypothetical patch, and years down the road, the program still has the > problem. The people who blocked the quick patch, naturally, never > bothered trying to write the patch they wanted.
The problem here is a quick patch makes the situation worse rather than better. That is the reason why the quick patch is rejected. > >> That's a mistranslation. It means that there are other criteria >> beyond some people having trouble. Such as, we really want multilibs >> to be built. > > Who is we here? And why do you really want multilibs built? The simple answer is testing, you should be build the multi-libs which are there for your target that means 32bit for x86_64. If you don't want them, explicitly disable them. The defaults are there for the majority of users and majority of users of compiling a compiler knows the risks of not having the current libraries installed. >>> I think you should detect the issue as *soon as practical* and then >>> *ALWAYS* emit a message that *TELLS THE USER WHAT TO DO*. >> >> Yes! Yes! Yes! > > Then what are we going to do about it? As per my first comment, nobody > has offered to produce a patch in the form you would be happy with, so > I'm not going to hold my breath that it's going to appear. That is because it is a hard to do and will force extra time in compiling and might cause incorrect handling of cross builds. Remember the host compiler does not have to compile for the multi-lib; only the newly compiled compiler will be able to. Thanks, Andrew Pinski > > -- > Kie ekzistas vivo, ekzistas espero.
