[Mesa-dev] Build failure since May 6

[tom fogal]

Brian Paul <brianp at vmware.com> writes:
> Kevin H. Hobbs wrote:
> > On 05/14/2010 08:51 AM, Dan Nicholson wrote:
> >> On Thu, May 13, 2010 at 7:40 AM, Kevin H. Hobbs <hobbsk at ohiou.edu> wrote:
> >>> I tried it and it tests as well with VTK as any recent build.
> >> Thanks. Well, you and Tom use a standalone osmesa. The only distro I
> >> looked at (fedora) uses a standalone osmesa. Maybe the build should
> >> just do that instead of trying to link to gl in some situations. It
> >> could certainly make the build a lot nicer. I'll try to put that into
> >> a formal patch since there's some other cleanup.
> > 
> > I am confused about the term "standalone osmesa" could you please tell
> > me if you mean :
> > 
> > 1. a build of Mesa where only libOSMesa.so is produced?
> > 
> > 2. a build of Mesa where libGL.so and libOSMesa.so are produced but the
> > dynamic linker will need no symbols from libGL.so in order to load
> > libOSMesa.so?
> > 
> > 3. a build of Mesa where libGL.so and libOSMesa.so are produced but the
> > dynamic linker will need symbols from libGL.so in order to load
> > libOSMesa.so.
[snip]
> Just some historical background: as originally designed, libOSMesa.so
> did not include the gl* entrypoints; you also had to link with
> libGL.so.  This allowed GLX and OSMesa to coexist and be used
> simultaneously within an app.
>
> I don't think many people still make use of that feature.  I think
> it's more common to build Mesa with name mangling to do OSMesa
> rendering with the mgl* functions and hardware rendering through the
> gl* functions (with any vendor's libGL).
>
> My preference now would be for option 2 (or 1) so that libOSMesa
> doesn't depend on libGL.so.

I think option 2 is what we get --with-driver=osmesa, mostly.. it just
doesn't build libGL.

To be honest, a standalone OSMesa isn't useful for us, because of how
VTK works.  To satisfy VTK, I currently build mangled Mesa AND mangled
OSMesa, and do a crazy cmake trick to make sure things work out (since
there are duplicate symbols, the -l order matters).

It would be *much* better for us if we could get a library which had
all of the OSMesa* functions, mangled glX symbols, and mangled gl
symbols.

That said, the use case of "just OSMesa" is probably still valid.. just
not something I personally care about in the short term.

-tom