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
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
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
@@ -43,9 +43,9 @@ libosmesa = shared_library(
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
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.
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 <firstname.lastname@example.org>. 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 :-(
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.
(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:
Author: Eric Engestrom <email@example.com>
Date: Thu May 2 12:42:48 2019 +0100
meson: expose glapi through osmesa
Suggested-by: Pierre Guillou <firstname.lastname@example.org>
Fixes: f121a669c7d94d2ff672 "meson: build gallium based osmesa"
Fixes: cbbd5bb889a2c271a504 "meson: build classic osmesa"
Cc: Brian Paul <email@example.com>
Cc: Dylan Baker <firstname.lastname@example.org>
Signed-off-by: Eric Engestrom <email@example.com>
Tested-by: Chuck Atkins <firstname.lastname@example.org>
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 :)