No. If OSMesa built with shared glapi depends on libGL, it's broken. This is supposed to be fixed in current versions of Mesa. (See also http://lists.freedesktop.org/archives/mesa-dev/2012-September/028019.html)

I insist on fixing this issue in wine's configure as it's needed for building (backporting) current wine devel versions (1.5.x) on current stable linux distributions that ship mesa 8.0.

And please notice that there are two different problems:
- test for glAccum that is not part of OSmesa library (it is much better to test for something that belongs to OSmesa and is not part of the OpenGL standard);
- possible requirement of glapi library to correctly link (if glapi is a shared library then it should be explicitly used in link commands as the current linux distro policies are to get rid of *.la files completely).

This can't be fixed in Wine, configure fails because OSMesa is *broken*. You say you tested those patches, but I doubt you actually have an application that uses the functionality in question.

(In reply to comment #3)
> You say you tested those patches, but I doubt you actually have an application that
> uses the functionality in question.

It seems at least Civilization III: Complete (Steam version) tries to make some use of it. Wine prints the following error when the game is loading to the main menu. This is with Wine compiled without OSMesa support:
>err:dib:dibdrv_wine_get_wgl_driver OSMesa not compiled in, no OpenGL bitmap support

I tried the Fedora version of the patch, but it didn't make it better. The error message changed to
>err:dib:init_opengl Failed to load OSMesa: /lib/libOSMesa.so.8: undefined symbol: _glapi_Dispatch
when Wine was compiled with that patch.

The only "app" (really game) that I can test is Civilization 3 (see
http://bugs.winehq.org/show_bug.cgi?id=30669 ). I've tested it on openSUSE 12.1
with mesa 8 and latest wine builds and it works if I install osmesa package.

If you wish I can test it once again on my current installation of Mageia 2
(that ships mesa 8 too) and my own builds of current wine git snapshots and
report the results.

Oh sorry, openSUSE 12.1 comes with even older mesa 7 and it also provides osmesa and it is required for Civ3.

Well... I've made some more testing and found that libosmesa is not really needed for Civ3 to work. At least it's not needed with current wine 1.5.14+.

So if you do not want to change the configure script you can close this bug with any resolution you like.

The configure script is correct, we can't use shared glapi OSMesa.

(In reply to comment #1)
> No. If OSMesa built with shared glapi depends on libGL, it's broken. This is
> supposed to be fixed in current versions of Mesa. (See also
> http://lists.freedesktop.org/archives/mesa-dev/2012-September/028019.html)

UPSTREAM then.

*** Bug 32974 has been marked as a duplicate of this bug. ***

Hi,

The upstream Mesa fix won't get distributions' libOSMesa right automatically.

It seems that libOSMesa need to be compiled without --enable-shared-glapi while other Mesa components need --enable-shared-glapi

Therefore, distributions need to build libOSMesa separately, which is not been done in Arch, Debian, Ubuntu currently.

Is this the right way to compile Mesa? Is there any distributions already do things right? Would you file bugs to distributions?

Thank you in advance.

(In reply to comment #11)
> Therefore, distributions need to build libOSMesa separately, which is not been
> done in Arch, Debian, Ubuntu currently.
> 
> Is this the right way to compile Mesa? Is there any distributions already do
> things right?

On Mageia we build Mesa twice (first the rest with shared-glapi, then OSMesa without it) for exactly this reason:
http://svnweb.mageia.org/packages/cauldron/mesa/current/SPECS/mesa.spec?revision=424801&view=markup

I wouldn't say this is the "right" way. It would be much better if Mesa was fixed so that a single build would be enough, but it seems to be non-trivial (at least to me), so this is what we ended up with.

There seems to be an upstream bug report about this issue:
https://bugs.freedesktop.org/show_bug.cgi?id=47824

Created attachment 44820 [details]
configure patched

I had to patch configure a little to make OSMesa be detectable, see attached file.

I posted a patch on the upstream bug, which should make osmesa work correctly again with shared glapi, without building twice.