Brian Paul <bri...@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 <hob...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev