Hi Brian,

On 14 May 2008, at 16:13, Brian Paul wrote:

> Dave Rigby wrote:
>> Greetings,
>> I'm currently trying to migrate an old in-house app (which no  
>> longer  have the source for) to a new Linux box. Previously this  
>> app ran on a  RH6.2 box, and I've noticed some strange behaviour in  
>> how this app  uses Mesa, specifically the glXUseXFont() function. I  
>> was seeing some  some font rendering issues; it looked like  
>> characters were getting  cropped.
>> I've tracked down the problem -  for some reason this app has it's  
>> own  implementation of Fake_glXUseXFont(). When the API function   
>> glXUseXFont (in mesa, libGL) is called, this calls the function  
>> which  does the real work (Fake_glXUseXFont) via a function table,  
>> and it  appears that this ends up getting resolved to it's own  
>> internal  Fake_glXUseXFont() symbol; instead of the function inside  
>> libGL (Mesa).
>> Now I've solved this for now by rebuilding Mesa and changing the  
>> Fake_  prefix to MesaImpl_ which stops the libGL function table  
>> finding this  app's symbol, but if possible I'd like to solve this  
>> in a way which  doesn't involve me maintaining patches on top of  
>> Mesa forever!
>> I'd like to understand the rationale for these Fake_* functions -  
>> is  what I have encountered by design (i.e. to allow apps to  
>> override the  default Mesa implementation), or is this behaviour  
>> purely accidental,  and these Fake_* symbols should have a more  
>> limited visibility (i.e.  hidden / internal); so they can never be  
>> overridden?
>> (note this is all pure software rendering; hardware accel is the  
>> next  step!.)
>> Any advice / info would be most appreciated.
>
> Mesa can basically be built in two ways for X: real GLX support  
> (with hardware rendering) or simulated GLX support (with software  
> rendering).  The later is implemented with the Fake_glx*()  
> functions.  We needed the Fake prefix to avoid collisions with  
> "real" implementation of GLX.
>
> If you're building Mesa with 'make linux' then you're getting fake  
> GLX support.  Building with 'make linux-dri' would give you real GLX  
> support and hardware acceleration if you have the right hardware.
>
> The problem of symbol overloading and the library errantly calling  
> app-provided functions shouldn't be happening because the Mesa libGL  
> is build with the -Bsymbolic flag.
>
> What application are you using?  Do you know why the app has its own  
> Fake_glXUseXFont() and why it's being used instead of the normal  
> glXUseXFont()?
>

It's an in-house app which was written a while ago, in true fashion by  
a group which no longer exists. I haven't got the source code for it;  
so I have no idea why it's got it's own Fake_glXUseXFont(). It does  
call via the public glXUseXFont() interface, hence my changing of the  
prefix fixing my problem.

I've had a quick look at my libGL and nm shows that the Fake_*  
functions are not marked as protected/symbolic. I see what you mean  
about -Bsymbolic; I can see that setting in the bin/mklib script. I  
built my (mesa) libGL.so from source, so I can only assume I messed  
something up during the build and didn't have that option set.

It sounds like I've been quite unlucky with user error - I'll rebuild  
Mesa again tomorrow, as it sounds like things should work fine of the  
function visibility is set correctly.

Thanks again,

Dave Rigby


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to