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

[tom fogal]

Tyson Whitehead <twhitehead at gmail.com> writes:
> On October 5, 2011 12:24:49 tom fogal wrote:
> > You need to mangle OSMesa.
> >
> > Mangled Mesa support is currently broken in VTK.  You might want to
> > follow my posts to the vtk-developers list; my group has fixed this
> > support (among other things) in a branch of 5.8.
>
> Thanks Tom.

You're very welcome.

> I've read through the last year of your posts to the vtk-developer list.  
> Here's a link (for anyone else following the discussion) to your last one 
> summarizing your current position
> 
> http://www.vtk.org/pipermail/vtk-developers/2011-August/010250.html
> 
> I also read around a bit about mangled OSMesa.  From what I can see
> 
> 1 - The Fedora libGL is not compiled with --enable-gl-osmesa and so does not 
> provide the OSMesa* functions.

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.

> 2 - The Fedora libOSMesa is not compiled with USE_MGL_NAMESPACE.

Yes, that's almost certainly true; I've never seen a package for
mangled Mesa, on any distro.

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.

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

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

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

> PS:  BTW, Good to hear VisIt is getting an update to the latest VTK
> too.

=)  We are happy about it too.  ... it had been far too long.

-tom