[Mesa-users] libGL and libOSMesa dispatch conflict issue on Fedora 14 build

[Tyson Whitehead]

On October 5, 2011 17:32:25 tom fogal wrote:
> Does --enable-gl-osmesa actually add OSMesa* functions to libGL, or
> just 'turn on' building libOSMesa at the same time libGL is built?
> 
> I am honestly asking; I do not remember.  I know there was some
> semi-recent (within past 6 months) changes or at least discussion about
> whether libOSMesa should be built from the .o's directly, or just built
> with -lGL so that it links into libGL for the gl* functions.

At the time I had presumed it added OSMesa* functionality to libGL as the 
description given in configure.ac was "enable OSMesa with libGL".

However, I can see how that could also means just build libOSMesa as well as 
libGL, and looking at what configure.ac actual does (adds osmesa to 
DRIVER_DIRS), I think this is most likely what would happen.


> I might argue that this is probably the way you want it, too: users
> might *want* a library which has the OpenGL symbols in a standard
> method.  Others (i.e. us) might want that same library with mangled
> symbols.  So a distribution probably requires 2 packages: 'osmesa' and
> 'osmesa-mangled'.
> 
> We could (probably) get a change upstream so that mangled libraries are
> named differently, e.g. libMangledGL and libMangledOSMesa.  If that
> helps distro packagers created packages for a mangled OSMesa, I will
> write up some patches.

I could see this would be useful all right.  Certainly makes more sense than 
require each package that wants it to have to compile a static version.

> > My understanding is then that the former implies the only way to get
> > OSMesa functionality is to compile up a seperated mangled OSMesa
> > library, while the later implies that this isn't libOSMesa as it
> > wasn't compiled that way.
> 
> Nah, OSMesa and mangling are orthogonal concerns/features.  They can be
> used together, or not.

I am a bit confused by that answer, but I think maybe that it because I failed 
to fully state what I was meaning/thinking of.  Let me try again.

My understanding then is that the only way to get OSMesa functionality at the 
same time as the regular GL functionality (i.e., use both libOSMesa and libGL 
in the same application) is to have the OSMesa is compiled with mangling.

(otherwise you get the multiple symbol resolution issue I ran into)

> > All together this means the Fedora VTK packaging is buggy as compiled
> > as it sets VTK_OPENGL_HAS_OSMESA on and VTK_USE_MANGLED_MESA off.
> 
> Yeah, sounds like it.  How could that work with, say, the nvidia
> driver?  There's no chance of nvidia's libGL having OSMesa functions in
> it.  So explicitly telling VTK libGL always has OSMesa functions does
> sound wrong to me, yes.

Yeah.  I can see how that would be a mess.  Interestingly enough, it sounds 
like the the MacOS libGL must have OSMesa functionality.

http://www.vtk.org/Wiki/VTK/OpenGL

> > It also means th at the only ways to enable OSMesa would be
> > 1 - Get your patches, build a custom mangled OSMesa, and compile
> > against it using VTK_OPENGL_HAS_OSMESA off and VTK_USE_MANGLED_MESA
> > on.
> 
> If you *needed* a short term fix, then yes.  I don't think the VTK
> folks would be very happy with you shipping our tree and calling it
> 'VTK'.  We need to get that upstreamed, and it will change during that
> process -- we've already started submitting it and they already dislike
> pieces, so bits are already changing.
> 
> > 2 - Recompile libGL to support OSMesa using --enable-gl-osmesa
> > and compile against it using using VTK_OPENGL_HAS_OSMESA on and
> > VTK_USE_MANGLED_MESA off.
> 
> For the above reason -- it's very possible that existent libGL's do
> *not* and *can*not have OSMesa symbols -- I highly discourage this
> option.

I think we are just going to go with just rebuilding the Fedora 14 VTK package 
with OSMesa functionality turned off for now.  I'll also open a bug report with 
them as well about the way they are compiling it.

Cheers!  -Tyson