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).
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.
(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)
Second is actually a question about whether it's possible or okay to use unversioned .so during build time
(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
> >
> >
> >> 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
> >>>
> >>>
> >>>> 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. SAMSUNG ELECTRONICS CO., LTD. TEL: +82-31-279-1091 |
|
|
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
