registry team mailing list archive

[Bug Watch Updater <248392@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 16 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=24766.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2009-10-27T11:40:04+00:00 Chow Loong Jin wrote:

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.

Reply at: https://bugs.launchpad.net/mesa/+bug/248392/comments/6

------------------------------------------------------------------------
On 2009-10-27T12:44:10+00:00 Julien Cristau wrote:

On Tue, Oct 27, 2009 at 11:40:05 -0700, bugzilla-daemon@xxxxxxxxxxxxxxx
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?

Reply at: https://bugs.launchpad.net/mesa/+bug/248392/comments/7

------------------------------------------------------------------------
On 2009-10-27T13:31:25+00:00 Chow Loong Jin wrote:

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.

Reply at: https://bugs.launchpad.net/mesa/+bug/248392/comments/9

------------------------------------------------------------------------
On 2009-10-27T14:09:35+00:00 Dbn-lists wrote:

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.

Reply at: https://bugs.launchpad.net/mesa/+bug/248392/comments/10

------------------------------------------------------------------------
On 2009-10-27T16:50:16+00:00 Chow Loong Jin wrote:

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.

Reply at: https://bugs.launchpad.net/mesa/+bug/248392/comments/11

------------------------------------------------------------------------
On 2009-10-27T17:26:47+00:00 Dbn-lists wrote:

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.

Reply at: https://bugs.launchpad.net/mesa/+bug/248392/comments/12

------------------------------------------------------------------------
On 2009-10-27T18:01:15+00:00 Corbin Simpson wrote:

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.

Reply at: https://bugs.launchpad.net/mesa/+bug/248392/comments/13

------------------------------------------------------------------------
On 2009-10-27T19:07:18+00:00 Chow Loong Jin wrote:

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

Reply at: https://bugs.launchpad.net/mesa/+bug/248392/comments/16

------------------------------------------------------------------------
On 2009-10-27T19:08:26+00:00 Chow Loong Jin wrote:

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

Reply at: https://bugs.launchpad.net/mesa/+bug/248392/comments/17

------------------------------------------------------------------------
On 2009-10-27T23:00:35+00:00 Dbn-lists wrote:

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

Reply at: https://bugs.launchpad.net/mesa/+bug/248392/comments/18

------------------------------------------------------------------------
On 2009-10-27T23:24:14+00:00 Chow Loong Jin wrote:

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

Reply at: https://bugs.launchpad.net/mesa/+bug/248392/comments/19

------------------------------------------------------------------------
On 2009-10-28T00:25:15+00:00 Chow Loong Jin wrote:

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.

Reply at: https://bugs.launchpad.net/mesa/+bug/248392/comments/20

------------------------------------------------------------------------
On 2009-10-28T03:36:33+00:00 Hverbeet wrote:

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

Reply at: https://bugs.launchpad.net/mesa/+bug/248392/comments/21

------------------------------------------------------------------------
On 2009-10-28T20:46:24+00:00 Dbn-lists wrote:

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

Reply at: https://bugs.launchpad.net/mesa/+bug/248392/comments/23

------------------------------------------------------------------------
On 2009-10-29T00:12:50+00:00 Chow Loong Jin wrote:

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

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

Reply at: https://bugs.launchpad.net/mesa/+bug/248392/comments/24

------------------------------------------------------------------------
On 2009-10-30T06:03:21+00:00 Dbn-lists wrote:

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. :)

Reply at: https://bugs.launchpad.net/mesa/+bug/248392/comments/25


** Changed in: mesa
   Importance: Unknown => High

** Bug watch added: freedesktop.org Bugzilla #23335
   http://bugs.freedesktop.org/show_bug.cgi?id=23335

-- 
32bit libgl search for dri at wrong place on 64bit system
https://bugs.launchpad.net/bugs/248392
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for Mesa.