[Dev] Building platform image with Mesa or Virtual driver in Tizen 3.0

Damian Hobson-Garcia dhobsong at igel.co.jp
Fri Jul 25 10:55:49 GMT 2014

On 2014-07-25 6:02 PM, Carsten Haitzler (The Rasterman) wrote:
> On Fri, 25 Jul 2014 16:35:25 +0900 Damian Hobson-Garcia <dhobsong at igel.co.jp>
> said:
>> Hi Carsten,
>> On 2014-07-25 3:46 PM, Carsten Haitzler (The Rasterman) wrote:
>>> On Fri, 25 Jul 2014 15:14:01 +0900 Damian Hobson-Garcia
>>> <dhobsong at igel.co.jp> said:
>>>> Hi Carsten,
>>>> On 2014-07-25 2:24 PM, Carsten Haitzler wrote:
>>>>> On 07/25/2014 02:13 PM, Damian Hobson-Garcia wrote:
>>>>>> Hi Carsten,
>>>>>> On 2014-07-25 1:07 PM, Carsten Haitzler wrote:
>>>>>>>>> Mesa could also be used during build time instead of the 
>>>>>>>>> opegl-es-virtual-drv.
>>>>>>>> Yes and no, I think.  There is the minor problem that the
>>>>>>>> Mesa drivers provide a versioned libGLESv2.so.2, which all of
>>>>>>>> the built packages will link to.  This means that if I want
>>>>>>>> to install a driver (such as Mali or SGX) after the fact, I
>>>>>>>> have to provide libGLESv2.so.2 to overwrite the Mesa driver.
>>>>>>>> If Mesa changes its version number for some reason, now the
>>>>>>>> Mali and SGX drivers must update their names as well.
>>>>>>>> opegl-es-virtual-drv is nice because it is not versioned, so
>>>>>>>> as long as there is a libGLESv2.so (or a link of that name)
>>>>>>>> in the non floss drivers, everything works.
>>>>>>> or just provide a symlink. far simpler a solution. drivers
>>>>>>> just ghave to agree all to provide at least the same symlink to
>>>>>>> the real driver version
>>>>>> I don't think it matters whether it's a symlink or not.  Either
>>>>>> way, it requires all of the drivers to keep track of whatever
>>>>>> version number that Mesa is using for its libGLESv2 and update
>>>>>> the symlink accordingly.
>>>>> for ABI compatibility, mesa can't just go changing major so
>>>>> version anyway as a binary links agains the major s at the time
>>>>> i'ts build. if they change major so version they are saying they
>>>>> broke ABI. so onse everyone is building against libGLxx.so.2 then
>>>>> it has to stay - unless they break ABI which they neever should.
>>>>> so it can be ASSUMED to always be that version - tizen as a
>>>>> platform has to force/define that and guarantee it across all tizen
>>>>> variations and versions. if we have to patch mesa (or just add
>>>>> special symlinks in pkgs) or do the same for other vendor gl
>>>>> drivers, thatis the price you pay to keep compatibility. that is
>>>>> what we have to do.
>>>> I agree that mesa shouldn't be changing their ABI, but if I have a
>>>> platform that never has and never will use Mesa drivers, why do I care
>>>> what they do with their ABI one way or the other? If I instead build
>>>> against something like opegl-es-virtual-drv, then its a complete
>>>> non-issue.  Then nothing needs to be forced or defined, and I don't
>>>> need any extra symlinks.
>>> you don't need a virtual driver lib at all - just something that is
>>> libGLxx.so.N that has the symbols. that's it. if thats mesa - so be it.
>>> ensure the libGLxx.so.N file exists (for real or a symlink). whatever that
>>> file is NOW in tizen is the abi you have to stick to.
>> Right, so if the ABI never changes, then neither will N. So would the
>> best solution then be to just not have N and just provide libGLxx.so
>> everywhere?
> no. because a .so is an unversioned lib and is always used as a symlink TO the
> actual major version at compiel time and the linker literally reads the link
> and doesnt link to libGL.so by libGL.so.N which it is pointing to. don't break
> conventions. this is the linux convention. inconsistency is bad.

Ok, but it seems that what you are proposing is breaking a similar
convention at runtime instead of compile.  If, for example the SGX or
Mali drivers provide a libGLxx.so or libGLxx.so.M, you're still creating
the libGLxx.so.N -> libGLxx.so or libGLxx.so.N -> libGLxx.so.M symlinks
which will seem odd.  It might not be as confusing as at compile time,
but the reason I was advocating for opegl-es-virtual-drv, is that it
avoids this kind of convention breaking/bending altogether.

Just to be clear, I'm not saying that Mesa should be abandoned or
anything like that, just that it might save a step or two for platforms
that don't use Mesa drivers if they build against the virtual drivers
instead. They should of course be free to build against Mesa and provide
symlinks if necessary if they like.


More information about the Dev mailing list