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