[Lsb-infrastructure] coping with glext/glxext

Denis Silakov silakov at ispras.ru
Thu Jun 23 02:03:02 PDT 2011


On 06/23/11 01:49, Wichmann, Mats D wrote:
>
> We have a bug on the fact that glext.h and glxext.h are not 
> conditionally included.  I thought I could at least fix that with 
> ConstantAttribute but even though header-deps are Constants, this is 
> not a place where ConstantAttribute is considered, apparently.

Yes, that's right.

> So the other two options seem to be, (1) import a bunch of stuff, 
> which I think is a little painful because of all of the conditional 
> stuff - or does libtodb2 do this successfully?  I'm not seeing how to 
> run it to just import the contents of a couple of headers - there are 
> no interface definitions involved, so there's no need to point at a 
> library.

You can safely import content of a standalone header using headertodb2 
tool - http://ispras.linuxfoundation.org/index.php/Headers_Analysis_Tool
Though it doesn't preserve ifdef conditions.

On the other hand, probably there is no need to have such conditions in 
generated headers, since we definitely know what is included in our 
gl.h/glx.h and what is absent there.

> Or (2) - just drop these two from LSB and package the OpenGL versions. 
>  That leaves us with a somewhat less complete description of the 
> system, true, but maybe that's not so important.
>

If I understood Craig correctly, 'improved' glext.h in LSB SDK would 
allow to build applications targeting higher OpenGL version than the one 
referenced by LSB (surely, only if no non-LSB binary symbols are used). 
So probably the actual question is - do we want to allow this?

I am not an OpenGL expert, but in general, application built for newer 
OpenGL version will not be LSB-compatible. For example, even if it uses 
only LSB symbols, it can use too new constants as function arguments and 
will crash on LSB-compatible system with older GL. (Unfortunately, 
appchk can't detect such aspects; dynchk could help here, if we ever 
manage to release it.) So maybe usage of improved glext.h should be 
considered as some kind of 'relaxed' mode for the SDK...

-- 
Regards,
Denis.




More information about the lsb-infrastructure mailing list