On Fri, 25 Jul 2014 19:55:49 +0900 Damian Hobson-Garcia <[email protected]> said:
> > > On 2014-07-25 6:02 PM, Carsten Haitzler (The Rasterman) wrote: > > On Fri, 25 Jul 2014 16:35:25 +0900 Damian Hobson-Garcia > > <[email protected]> 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 > >>> <[email protected]> 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. no - i'm not. i'm saying that you have always had: libGL.so -> libGL.so.N libGL.so.N -> libGL.so.N.M libGL.so.M the libGL.so symlink ONLY ships in dev/devel packages along with headers etc. - this is ONLY used at link time to determine what to link to (what it points to) this is how it has ALWAYS been on linux as far as i can remember (and other unixes i know). either way it is THE convention on modern linux. if you have libGL.so.X instead of libGL.so.N produced by drivers then either when packaged just: mv libGL.so.X libGL.so.N mv libGL.so.X.M libGL.so.N.M or add a symlink: ln -s libGL.so.X libGL.so.N ensure that libGL.so.N is there. that is all you need. who provides it is irrelevant. you know that the driver packages re compiled and packaged too - so what if its mesa or not - the file CAN be renamed to support tizen conventions/abi > 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. that step needs to be no more than a symlink (or a rename of files). anything more complex is hurting the platform by complexity it does not need. :) -- Carsten Haitzler (The Rasterman) <[email protected]> _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
