Comment 19 for bug 248392

(In reply to comment #9)
> (In reply to comment #7)
> > @Dan Nicholson: Sticking 64-bit libraries into /usr/lib64 instead of /usr/lib
> > would require changing Debian's packaging policy as well as every derivative of
> > Debian's policy to accomodate one library that won't work otherwise.
>
> So debian's policy is that 32 bit libraries go in /usr/lib32 on x86_64 but
> their 32 bit libraries aren't actually installed there? So, is this is
> multiarch or not? It sounds like it's not intended to be multiarch.
It's not trivial to change the userland, and the package manager does not natively support multiarch. ia32-libs exists because of the need for 32-bit libraries in 64-bit.

> I would agree with Corbin that this is NOTABUG since this case is pretty
> convoluted and no one has ever needed it before. However, if you write a patch
> that sets the search path from configure and leaves the current default (not
> extending it with a path that hasn't been needed), then I'll commit it for you.
Will do.

> You may want to open a bug in ubuntu to see what the developers say. If this is
> a debian/ubuntu policy, then I don't know why it hasn't come up before.
I'm not sure about ia32-libs' history as I've only switched to 64-bit Ubuntu relatively recently (after Ubuntu 9.04's release), but I've talked to other developers and am personally an Ubuntu Contributing Developer myself. The bug in Ubuntu which I linked in comment #8 was filed on 2008-07-14, but never really got much attention, probably because not many actually played 32-bit GPU intensive games on 64-bit Ubuntu with Intel graphics.

I myself did not notice that Wine was not getting direct rendering until the whole issue with Wine segfaulting as a result of a bad FBO returned by mesa under indirect rendering took place.