On Sat, 26 Jul 2014 01:04:49 +0000 (GMT) 하상원 <[email protected]> said:
> Samsung Enterprise Portal mySingle > > Dear Carsten and Damian, > > > > Please correct if I'm wrong. > > First, about the versioned .so. > > During build time, compilers of other packages requiring OpenGL capability > needs libGL.so > > and linkers needs libGL.so.N (just the link name not the library itself), > both of which are symbolic links. > > The actual implementation goes into libGL.so.N.M after building the DDK > usually provided by the GPU vendor. > > So the driver will have the following created: > > > > libGL.so -> libGL.so.N > > libGL.so.N -> libGL.so.N.M > > libGL.so.N.M (the actual implementation) > > > > Now, the GPU vendor (or, Mesa for that matter) decides to upgrade the version > number specific to its > > implementation and starts releasing libGL.so.N.X, and the libGL.so.N.M is > replaced with the new libGL.so.N.X > > in the target device. > > Since other packages weren't tied to the minor version number in the first > place, those pkgs should function > > normally as before assuming ABI is maintained. > > So, the GPU vendor should never increase the major version (aka. "N" in > libGL.so.N), but is free to increase > > the minor version (aka. "M" in libGL.so.M). correct. if the original vendor gl driver does not follow this major version, it needs to be fixed in packages. if not fixed it's "tizen incompatible". for tizen 2.x it's libGLESv2.so.2 - so major version 2. there is no reason for tizen 3 to go breaking abi here too. :) > In this sense, any OpenGL driver (inc. Mesa, opengl-es-virtual-drv, or H/W > GPU driver) is at the same > > starting line in terms of our discussion about which is appropriate for build > time OpenGL package. build time doesn't much matter. as long as you have a library with .so.2 major version and a .so saymlink pointing to it, and that major version is either the lib itself or is another symlink to the .so.2.X .. and the final .so has the symbols needed (basic gles2 symbols in this case), you're fine. > (Will using Mali driver during build time cause licensing issue? even if not > released afterwards, leaving > > the sym. links intact but removing libGL.so.N.M? - there's no libGL for Mali > but to keep consistency in terminology) no license issues as no dynamic linking license implications there (gpl is different). headers are the std khronos stuff anyway so "moot" (and if they were not we can just steal/copy the mesa or chronos files which is what all this is anyway realistically) > Second is actually a question about whether it's possible or okay to use > unversioned .so during build time no (assuming you mean only have a .so with no versions). the version (major) is determined by following the first .so link. you inlclude the .so link and it should point to .so.2 - that .so.2 is what your binary then relies on at runtime. > (no libGL.so.N or libGL.so.N.M so compilers and linkers will only be aware of > libGL.so) and at runtime be > > using libGL.so.N.M if the necessary sym. links are created before executing > any packages using OpenGL. > > > > Best regards, > > Sangwon Ha > > > > ------- Original Message ------- > > Sender : Carsten Haitzler<[email protected]> > > Date : 2014-07-26 01:10 (GMT+09:00) > > Title : Re: [Dev] Building platform image with Mesa or Virtual driver in > Tizen 3.0 > > On Fri, 25 Jul 2014 19:55:49 +0900 Damian Hobson-Garcia > 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 > > > 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 > > >>> 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) > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev > > > ------------------------------------------------ > > > > > > > > > > > > > HA, SANGWON, Ph.D. > Senior Engineer > > System S/W Lab, S/W Platform Team, > S/W Center > > SAMSUNG ELECTRONICS CO., LTD. > 129 Samsung-Ro, Maetan-Dong, > Yeongtong-Gu, Suwon, > Gyeonggi-Do, Korea 443-742 > > TEL: +82-31-279-1091 > FAX: +82-31-279-2348 > MOBILE: +82-10-3199-8833 > E-mail: [email protected] > > ------------------------------------------------ > > > > -- Carsten Haitzler (The Rasterman) <[email protected]> _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
