32bit libgl search for dri at wrong place on 64bit system

Created an attachment (id=30758)
Additionally search in /usr/lib/dri/<host, e..g. i486-pc-linux.gnu>/ for DRI modules

On Ubuntu Karmic x86_64, all 32-bit applications which use DRI fail to have Direct Rendering due to libGL.so searching in /usr/lib/dri, which contains 64-bit DRI modules instead of /usr/lib32/dri.

One of the bugs that this has caused is http://bugs.winehq.org/show_bug.cgi?id=20448, which occurs in combination with http://bugs.freedesktop.org/show_bug.cgi?id=23335.

On Tue, Oct 27, 2009 at 11:40:05 -0700, <email address hidden> wrote:

> On Ubuntu Karmic x86_64, all 32-bit applications which use DRI fail to have
> Direct Rendering due to libGL.so searching in /usr/lib/dri, which contains
> 64-bit DRI modules instead of /usr/lib32/dri.
>
> One of the bugs that this has caused is
> http://bugs.winehq.org/show_bug.cgi?id=20448, which occurs in combination with
> http://bugs.freedesktop.org/show_bug.cgi?id=23335.

sounds like a packaging issue rather than a mesa bug?

Well, the other way would be to recompile every 32-bit library within ia32-libs with --libdir=/usr/lib32, which doesn't seem like a particularly good idea to me either.

Why not just build mesa so that the paths are correct? There's even a switch, --with-dri-driverdir, that sets this correctly. I don't think things will work correctly if they get moved around after the installation. If Ubuntu multiarch uses /usr/lib32 for 32 bit libraries, why not just build with --libdir=/usr/lib32?

If we really want to extend the search path, I'd rather keep the current default and allow overriding with --with-dri-searchpath or something.

Building with --libdir=/usr/lib32 won't work, since 32-bit machines do use /usr/lib after all. The whole point of this was to avoid the requirement of rebuilding with different configure arguments, so that all the 32-bit libraries can be treated the same way (just repacking) for the multiarch ia32-libs package.

As for --with-dri-searchpath, I think that can be handled without too many changes to the build system. If you're sure you'd like it that way, I can come up with a patch to make it that way. I just don't have a lot of time to spare a the moment and don't want to come up with numerous patches that get rejected one by one.

I don't think you can have it both ways. If your system's ABI is 32 bit in /usr/lib32 and 64 bit in /usr/lib, then you should probably build the binaries that way. If you want your system's ABI to be compatible with a 32 bit only system, then put the 64 bit libraries in /usr/lib64 like everybody else.

Mesa libGL is certainly not the only library that dlopen's modules from private directories. What would you do about, say, gstreamer?

I would commit a patch that changes the search path via a configure argument as long as it doesn't change the default.

Multilib distributions always have extra baggage on their shoulders, and this is just one more bit of it. I'm really struggling to see how this is our problem when we've got not just a compile-time flag (--with-dri-driverdir) but also a run-time environment variable (LIBGL_DRIVERS_PATH) to configure this.

I'd like to close as NOTOURBUG, but I'd like to make sure that nobody else wants to follow up on this. I also heavily encourage the original reporter to follow up with Ubuntu directly.

@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.

I'm not actually sure about what the case is like for GStreamer. However, the approach I am proposing is actually used within Gtk for loading modules which are usually found in /usr/lib/gtk-2.0 (i.e. it also searches within /usr/lib/gtk-2.0/<GTK_HOST> where GTK_HOST is defined to the $host found from configure. In fact, https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/369498 is what I was referring to when I came up with the patch.

@Corbin Simpson: The compile time flag --with-dri-driverdir would fail if I set more than one path there, e.g. /usr/lib/dri:/usr/lib/dri/i486-pc-linux-gnu, and the LIBGL_DRIVERS_PATH environment variable would require that every 64-bit user running 32-bit OpenGL applications set the environment variable, which is hardly what I would consider appropriate.

Also, you both were mentioning "changing the defaults". The patch I propose does not change the defaults, it just adds an extra search path. The original search path is preserved.

Either way, if you wouldn't mind committing a patch that changes the path via a configure argument, then I'll just write up a patch that does that instead.

For reference, https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/248392 is the original bug downstream.

(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.

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.

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.

(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.

Created an attachment (id=30761)
Add --with-dri-driver-searchdirs configure flag

This patch adds the --with-dri-driver-searchdirs configure flag which will append the provided path to ${DRI_DRIVER_SEARCH_DIR} if present.

(In reply to comment #9)
> 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.
>
For what it's worth, we do get a number of bug reports from people with broken 32 bit OpenGL setups both for Wine and CrossOver, so the issue certainly isn't new. Wine using FBOs by default in combination with bug 23335 just made it a lot more noticeable for most people. Ultimately it's the responsibility of the distribution to not screw this up, but if Mesa can do anything to make that easier that's appreciated of course.

(In reply to comment #11)
> Created an attachment (id=30761) [details]
> Add --with-dri-driver-searchdirs configure flag
>
> This patch adds the --with-dri-driver-searchdirs configure flag which will
> append the provided path to ${DRI_DRIVER_SEARCH_DIR} if present.

That looks good, but I don't think $DRI_DRIVER_INSTALL_DIR should be forced in ahead of the user value. If they decide to override the default, they should be in full control of the path. Also, do you mind chaning the option to --with-dri-searchpath to keep it a little more concise?

Created an attachment (id=30786)
Add --with-dri-searchpath configure flag

As requested, it is --with-dri-searchpath now.

Pushed as 35506dec6734a1ae777dc16981cb19e514f41897 with an additional change so the dri pkgconfig file doesn't break.

Thanks. Now you just have to get the Ubuntu people to rebuild in the right way. :)