Bug 109659

Summary:	Missing OpenGL symbols in OSMesa Gallium when building with meson
Product:	Mesa	Reporter:	Pierre Guillou <pierre.guillou>
Component:	Drivers/OSMesa	Assignee:	mesa-dev
Status:	RESOLVED FIXED	QA Contact:	mesa-dev
Severity:	normal
Priority:	medium	CC:	baker.dylan.c, brianp
Version:	18.3
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Pierre Guillou 2019-02-18 09:24:55 UTC

Building OSMesa Gallium with meson leads to missing exported OpenGL symbols in libOSMesa.so compared to using the autotools/configure script.

Use case/context: ParaView in-situ analysis and rendering (https://blog.kitware.com/messing-with-mesa-for-paraview-5-0vtk-7-0/)

When using meson to build OSMesa from Mesa 18.3:

$ meson [sourcedir] -Dosmesa=gallium
$ ninja

I noticed that libOSMesa.so does not export OpenGL symbols:

$ nm -D src/gallium/targets/osmesa/libOSMesa.so | grep " T "
000000000006cbe0 T OSMesaColorClamp
000000000006c6a0 T OSMesaCreateContext
000000000006c1a0 T OSMesaCreateContextAttribs
000000000006c620 T OSMesaCreateContextExt
000000000006cc60 T OSMesaDestroyContext
000000000006c0a0 T OSMesaGetColorBuffer
000000000006c0f0 T OSMesaGetCurrentContext
000000000006cf50 T OSMesaGetDepthBuffer
000000000006c6c0 T OSMesaGetIntegerv
000000000006cb70 T OSMesaGetProcAddress
000000000006c7d0 T OSMesaMakeCurrent
000000000006cc00 T OSMesaPixelStore
000000000006cee0 T OSMesaPostprocess

However, using the autotools/configure script (Mesa 18.3):

$ [sourcedir]/autogen.sh --enable-gallium-osmesa
or, from release tarball
$ [sourcedir]/configure --enable-gallium-osmesa
$ make

the generated library exports the whole OpenGL API:

$ nm -D lib/gallium/libOSMesa.so | grep " T "
0000000000558f80 T glAccum
000000000055e300 T glActiveShaderProgram
[...]
000000000055ae40 T glWindowPos3sv
000000000055ae40 T glWindowPos3svARB
0000000000557200 T OSMesaColorClamp
00000000005569d0 T OSMesaCreateContext
00000000005564d0 T OSMesaCreateContextAttribs
0000000000556950 T OSMesaCreateContextExt
0000000000557280 T OSMesaDestroyContext
00000000005563d0 T OSMesaGetColorBuffer
0000000000556420 T OSMesaGetCurrentContext
0000000000556ea0 T OSMesaGetDepthBuffer
00000000005569f0 T OSMesaGetIntegerv
0000000000557190 T OSMesaGetProcAddress
0000000000556b00 T OSMesaMakeCurrent
0000000000557220 T OSMesaPixelStore
00000000005572b0 T OSMesaPostprocess

This behavior has been witnessed on up-to-date ArchLinux and Ubuntu 18.04.

Assuming this is a bug in the Meson build script, one quick fix would be to edit src/gallium/targets/osmesa/meson.build and move libglapi_static from the link_with section to the link_whole section in the osmesa library declaration:

diff --git a/src/gallium/targets/osmesa/meson.build b/src/gallium/targets/osmesa/meson.build
index b4ae8f4b6ec..e873e311aa0 100644
--- a/src/gallium/targets/osmesa/meson.build
+++ b/src/gallium/targets/osmesa/meson.build
@@ -43,9 +43,9 @@ libosmesa = shared_library(
     inc_gallium_drivers,
   ],
   link_depends : osmesa_link_deps,
-  link_whole : [libosmesa_st],
+  link_whole : [libosmesa_st, libglapi_static],
   link_with : [
-    libmesa_gallium, libgallium, libglapi_static, libws_null, osmesa_link_with,
+    libmesa_gallium, libgallium, libws_null, osmesa_link_with,
   ],
   dependencies : [
     dep_selinux, dep_thread, dep_clock, dep_unwind,

However, being quite new at building Mesa and maybe missing the big picture, I'm not sure
* if what I'm describing here is really a bug, or is intentional and
* if there is some unforeseen consequences of the aforementioned quick fix.

Is there a more appropriate way to use OpenGL through OSMesa?

Similar to: https://bugs.freedesktop.org/show_bug.cgi?id=94489

Comment 1 Dylan Baker 2019-02-19 15:27:33 UTC

I think your suggestion to use `link_Whole` is probably the correct one, autotools has the link whole behavior by default in that case. I just want to Cc Brian, who knows how osmesa is supposed to work.

Comment 2 Chuck Atkins 2019-05-17 13:31:55 UTC

I can confirm that the proposed patch, https://lists.freedesktop.org/archives/mesa-dev/2019-May/218700.html, fixes the bug.

Please add Tested-by: Chuck Atkins <chuck.atkins@kitware.com>.  This should also go to all stable branches and is really should be a blocker for 19.1 since OSMesa is unusable without it.

I'd reply on the mailing list but in doing some cleanup I wiped out everything older than week :-(

Comment 3 Chuck Atkins 2019-05-17 17:53:53 UTC

I spoke a little too soon but I think this patch is still okay.  llvmpipe and softpipe work fine but swr is mysteriously broken.  What I don't know is if swr is broken with osmesa because of this or something else.  So given that, I'm okay with aserting that the fix addresses the specific issues of missing gl symbols in OSMesa and having swr being broken in OSMesa as a different problem to be addresses separately.

Comment 4 Eric Engestrom 2019-05-18 10:22:45 UTC

(In reply to Chuck Atkins from comment #3)
> I spoke a little too soon but I think this patch is still okay.  llvmpipe
> and softpipe work fine but swr is mysteriously broken.  What I don't know is
> if swr is broken with osmesa because of this or something else.  So given
> that, I'm okay with aserting that the fix addresses the specific issues of
> missing gl symbols in OSMesa and having swr being broken in OSMesa as a
> different problem to be addresses separately.

OK, I pushed the fix, so I'm marking this issue as fixed by:

commit ccb8ea7acfb710c6c5298f3ffcadbe3d79b9b913
Author: Eric Engestrom <eric.engestrom@intel.com>
Date:   Thu May 2 12:42:48 2019 +0100

    meson: expose glapi through osmesa
    
    Suggested-by: Pierre Guillou <pierre.guillou@lip6.fr>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109659
    Fixes: f121a669c7d94d2ff672 "meson: build gallium based osmesa"
    Fixes: cbbd5bb889a2c271a504 "meson: build classic osmesa"
    Cc: Brian Paul <brianp@vmware.com>
    Cc: Dylan Baker <dylan@pnwbakers.com>
    Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
    Tested-by: Chuck Atkins <chuck.atkins@kitware.com>

BTW, the `Fixes:` tags mean that this will be backported to 19.0 & 19.1

Please open a new bug with your findings about SWR :)

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.