[Mesa-dev] Build failure since May 6

Brian Paul brianp at vmware.com
Fri May 14 07:58:36 PDT 2010


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.
>>
>> --
>> Dan
>>
> 
> I look forward to the patch.
> 
> 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.
> 
> I have been using the build target :
> 
> make linux-x86-64
> 
> to test VTK and ParaView.
> 
> I believe this build target is the case 3 above which sounds to me like
> "standalone Mesa" but not really "standalone OSMesa" which could be
> cases 1 and 2 above.
> 
> The build target created by configure --with-driver=xlib also seems to
> be case 3 above but because of the hidden symbols problem from
> -fvisibility=hidden your patch will make this target produce case 2 above.
> 
> Is all that correct?

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.

-Brian


More information about the mesa-dev mailing list