Wine is unable to detect OSMesa correctly when compiling from source

[Jaime Rave]

I'm trying to compile Wine from source but everytime i run ./configure i got at the end of the log:
configure: libOSMesa development files not found (or too old), OpenGL rendering in bitmaps won't be supported.

There was a bug filled in wine-bugs but they say is a problem in mesa http://bugs.winehq.org/show_bug.cgi?id=31904, the issue is supposed to be fixed in Mesa 9.0 but i have updated to version 9.0-0ubuntu1 and I'm still getting this error.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: libosmesa6-dev 9.0-0ubuntu1
ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
Uname: Linux 3.5.0-17-generic i686
.tmp.unity.support.test.0:

ApportVersion: 2.6.1-0ubuntu3
Architecture: i386
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell]
CompositorRunning: compiz
Date: Sun Oct 14 16:33:55 2012
DistUpgraded: 2012-06-27 12:51:06,634 DEBUG enabling apt cron job
DistroCodename: quantal
DistroVariant: ubuntu
DkmsStatus: virtualbox, 4.1.18, 3.5.0-17-generic, i686: installed
ExtraDebuggingInterest: Yes
GraphicsCard:
 Advanced Micro Devices [AMD] nee ATI Madison [Mobility Radeon HD 5000 Series] [1002:68c0] (prog-if 00 [VGA controller])
   Subsystem: Hewlett-Packard Company Device [103c:1594]
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta i386 (20120419)
MachineType: Hewlett-Packard HP Pavilion dv6 Notebook PC
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-17-generic root=UUID=d8f2140b-0c50-4d83-9991-c03e9a2a89a4 ro quiet splash vt.handoff=7
SourcePackage: mesa
UpgradeStatus: Upgraded to quantal on 2012-06-27 (109 days ago)
dmi.bios.date: 07/26/2011
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: F.0F
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: 1594
dmi.board.vendor: Hewlett-Packard
dmi.board.version: 91.36
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnHewlett-Packard:bvrF.0F:bd07/26/2011:svnHewlett-Packard:pnHPPaviliondv6NotebookPC:pvr058B200000242B10000020100:rvnHewlett-Packard:rn1594:rvr91.36:cvnHewlett-Packard:ct10:cvrChassisVersion:
dmi.product.name: HP Pavilion dv6 Notebook PC
dmi.product.version: 058B200000242B10000020100
dmi.sys.vendor: Hewlett-Packard
version.compiz: compiz 1:0.9.8.4-0ubuntu2
version.libdrm2: libdrm2 2.4.39-0ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 9.0-0ubuntu1
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 9.0-0ubuntu1
version.xserver-xorg-core: xserver-xorg-core 2:1.13.0-0ubuntu6
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.3-0ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.99.99~git20120913.8637f772-0ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.20.9-0ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.2-0ubuntu3

[Jonathan Liu (net147-t)]

Configure command:
./configure --prefix=/usr --with-dri-driverdir=/usr/lib/xorg/modules/dri --with-gallium-drivers=r300,r600,nouveau,svga,swrast --enable-gallium-llvm --enable-gallium-egl --enable-shared-glapi --enable-glx-tls --enable-dri --enable-glx --enable-osmesa --enable-gles1 --enable-gles2 --enable-egl --enable-texture-float --enable-xa --enable-shared-dricore

When compiling mesa with osmesa and --enable-shared-glapi, OpenGL functions such as glNormal3f, glVertex3f, etc. are not defined in libOSMesa but are defined in libGL. It would be good if there was an option to build libOSMesa with static GL API and the rest built with shared GL API at the same time. This means if libGL is replaced with a proprietary libGL, libOSMesa can still continue to function properly.

[Olelukoie (olelukoie)]

When I run configure script for latest wine 1.5.x releases it always reports that it can not find OSMesa but I have it installed correctly.

Looking for a solution I've found several versions of patch that fixes this. For example this is the Gentoo version:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emulation/wine/files/wine-1.5.10-osmesa-check.patch

and this is Fedora version:

http://pkgs.fedoraproject.org/cgit/wine.git/tree/wine-1.5.10-osmesa-check.patch?h=f17

I've tested Fedora version of the patch and it works well for me (I'm using mageia linux).

[Hverbeet (hverbeet)]

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)

[Olelukoie (olelukoie)]

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

[Hverbeet (hverbeet)]

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.

[Gyebro69 (gyebro69)]

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

[Olelukoie (olelukoie)]

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.

[Olelukoie (olelukoie)]

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

[Olelukoie (olelukoie)]

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.

[Alexandre Julliard (julliard)]

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

[Austin English (austinenglish)]

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

[Jaime Rave (jaimerave)]

I'm attaching the config.log that Wine genereated when compiling from source.

[AG Restringere (ag-restringere-deactivatedaccount)]

Jamie, you should probably try the following 'https://launchpad.net/~ubuntu-wine' as they might be able to help you more as this is not really a graphics or video related issue. It's usually one of those annoying things about compiling programs from scratch is the "easter egg hunt" of getting all the dependencies and this is why most people just use PPA's.

My guess is to try installing that package 'li for quantal and trying again...
http://packages.ubuntu.com/pt/quantal/libosmesa6-dev

You might also want to verify this is available by doing in Terminal:

:~$ apt-cache search libosmesa6-dev
libosmesa6-dev - Mesa Off-screen rendering extension -- development files

However, you should probably go to 'https://launchpad.net/~ubuntu-wine' as they might have the entire software already compiled for you or would have loads of experience with it.

[AG Restringere (ag-restringere-deactivatedaccount)]

Btw, in the above navigate to https://launchpad.net/~ubuntu-wine

[Jaime Rave (jaimerave)]

Hi AG, I already have installed libosmesa6 and libosmesa6-dev, and Wine is unable to find them, that's why i'm filling the bug. The problem with using the ubuntu-wine packages is that they only provide a package of the latests release, but I'm trying to compile the daily version to test the new commits.

[AG Restringere (ag-restringere-deactivatedaccount)]

This appears to be a problem with WineHQ and not the packages as upstream indicates this problem was fixed https://bugs.freedesktop.org/show_bug.cgi?id=53179. In synaptic can you verify the version of libosmesa6-dev and also try pulling down the latest git for WineHQ and trying again.

[Jaime Rave (jaimerave)]

I have installed libosmesa6-dev version 9.0-0ubuntu1, I have retested with the latest git from wine and the problem is still there.

[Jaime Rave (jaimerave)]

It's also an issue with the package in Xorg-edgers, libosmesa and libosmesa-dev version 9.1~git20121020.d2b0338e-0ubuntu0ricotz

[Rafael Witten (rafiwitten)]

I don't know anything about wine but it looks to me like something might have changed in the libosmesa6-dev package.

I am using the libosmesa6-dev package on Ubuntu and it seems like the recent update to 9.0-0ubuntu1 from 8.0.4-0ubuntu0.1 broke my compile. After the update my project couldn't link - g++ couldn't find any of the gl-prefixed functions (glBegin, etc). Some debugging showed

readelf --symbols /usr/lib/x86_64-linux-gnu/libOSMesa.so

seemed to be missing the necessary functions, so I reverted to 8.0.4-0ubuntu0.1. My compile was fixed and readelf showed the appropriate functions.

[Jaime Rave (jaimerave)]

This is also a problem in Ubuntu 13.04 with packages libosmesa and libosmesa-dev version 9.0-0ubuntu1

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jaime Rave (jaimerave)]

I have opened a new bug with the Wine team since I have tested with Mesa 9.2 from xorg-edgers and I'm still getting the same error. The link to the bug is: http://bugs.winehq.org/show_bug.cgi?id=32974

[Jaime Rave (jaimerave)]

According to a comment in Wine, the issue could be that Mesa is been build with shared glapi. How can I verify if this is the case?

[Alexandre Julliard (julliard)]

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

[Scott Ritchie (scottritchie)]

The linked os mesa bug says it was fixed in 9.0, and Ubuntu seems to have a version later than that available (in raring as well), is this still an issue?

[Jaime Rave (jaimerave)]

Still a problem in Saucy

[Ma Hsiao-chun (mahsiaochun)]

The upstream fix basically make it _possible_ to compile OSMesa without shared glapi.

It seems that Mesa components except OSMesa do need --enable-shared-glapi .

So I currently work around this issue as I don't install libosmesa* from the repository.

Instead, I compile libOSMesa manually as:
# Download and untar Mesa source
autoreconf -fi
./configure --enable-shared --disable-static --enable-texture-float
--enable-osmesa --disable-gallium-llvm --disable-dri --disable-egl
--disable-glx --with-gallium-drivers= --with-dri-drivers=
make
sudo make install
sudo ldconfig

[Ma Hsiao-chun (mahsiaochun)]

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.

[Anssi Hannula (anssi-hannula)]

(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

[Scott Ritchie (scottritchie)]

Am I right that if you never have proprietary libgl on your system then Wine builds properly?

That would explain why the build daemons seem to get it right but this problem hits users desktops.

[Ma Hsiao-chun (mahsiaochun)]

From my experience on Saucy, it doesn't matter whether proprietary driver is enabled or not.

The message is just a warning at the end of configure, not a stopper.

[A-roland (a-roland)]

Created attachment 44820
configure patched

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

[Maarten Lankhorst (mlankhorst)]

Created attachment 82036
fix?

I have no idea how much this helps, but give it a shot..

[Maarten Lankhorst (mlankhorst)]

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

[Launchpad Janitor (janitor)]

This bug was fixed in the package mesa - 9.1.4-0ubuntu3

---------------
mesa (9.1.4-0ubuntu3) saucy; urgency=low

  * Add fix-os-mesa-exports.diff from upstream. (LP: #1066599)
 -- Maarten Lankhorst <email address hidden> Tue, 16 Jul 2013 11:29:32 +0200