Message ID | cover.1343823907.git.ross.burton@intel.com |
---|---|
State | New |
Headers | show |
Op 1 aug. 2012, om 14:31 heeft Ross Burton <ross.burton@intel.com> het volgende geschreven: > This patch series upgrades mesa-dri to the latest upstream, enables GLES2 and > EGL That will sadly break all the powervr based evil binaries (e.g. all cortex arm chips from TI) since there will be 2 providers of those libs. I looked at this a few years ago (when mesa gained libegl) and I couldn't come up with a solution other than "don't build it" :( That solution also breaks a number of usecases but back then I had the liberty to not care about those. Does anyone have suggestions on how to handle this? regards, Koen
On 1 August 2012 14:32, Koen Kooi <koen@dominion.thruhere.net> wrote: > That will sadly break all the powervr based evil binaries (e.g. all cortex arm chips from TI) since there will be 2 providers of those libs. I looked at this a few years ago (when mesa gained libegl) and I couldn't come up with a solution other than "don't build it" :( That solution also breaks a number of usecases but back then I had the liberty to not care about those. > Does anyone have suggestions on how to handle this? Rename the mesa ones to libegl-mesa (etc), and encourage TI to use libegl-ti? Ross
Op 1 aug. 2012, om 15:41 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven: > On 1 August 2012 14:32, Koen Kooi <koen@dominion.thruhere.net> wrote: >> That will sadly break all the powervr based evil binaries (e.g. all cortex arm chips from TI) since there will be 2 providers of those libs. I looked at this a few years ago (when mesa gained libegl) and I couldn't come up with a solution other than "don't build it" :( That solution also breaks a number of usecases but back then I had the liberty to not care about those. >> Does anyone have suggestions on how to handle this? > > Rename the mesa ones to libegl-mesa (etc), and encourage TI to use libegl-ti? Recipe names don't matter, the .so files in sysroots and shlibdeps do.
On 1 August 2012 15:33, Koen Kooi <koen@dominion.thruhere.net> wrote: >> Rename the mesa ones to libegl-mesa (etc), and encourage TI to use libegl-ti? > > Recipe names don't matter, the .so files in sysroots and shlibdeps do. I meant the name of the generated package. libegl-mesa and libegl-ti shipping the same libraries is expected and desired. Ross
On 1 August 2012 14:32, Koen Kooi <koen@dominion.thruhere.net> wrote: > > Op 1 aug. 2012, om 14:31 heeft Ross Burton <ross.burton@intel.com> het volgende geschreven: > >> This patch series upgrades mesa-dri to the latest upstream, enables GLES2 and >> EGL > > That will sadly break all the powervr based evil binaries (e.g. all cortex arm chips from TI) since there will be 2 providers of those libs. Why could one prefer providers of virtual/libgles2 and virtual/ligegl on a per-machine basis. This maps quite well with the reality.
Op 1 aug. 2012, om 16:34 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven: > On 1 August 2012 15:33, Koen Kooi <koen@dominion.thruhere.net> wrote: >>> Rename the mesa ones to libegl-mesa (etc), and encourage TI to use libegl-ti? >> >> Recipe names don't matter, the .so files in sysroots and shlibdeps do. > > I meant the name of the generated package. libegl-mesa and libegl-ti > shipping the same libraries is expected and desired. That won't work with debian renaming and shlib will pick up both anyway. You can only have one libegl.so *ever* during the build.
Op 1 aug. 2012, om 16:38 heeft Damien Lespiau <damien.lespiau@gmail.com> het volgende geschreven: > On 1 August 2012 14:32, Koen Kooi <koen@dominion.thruhere.net> wrote: >> >> Op 1 aug. 2012, om 14:31 heeft Ross Burton <ross.burton@intel.com> het volgende geschreven: >> >>> This patch series upgrades mesa-dri to the latest upstream, enables GLES2 and >>> EGL >> >> That will sadly break all the powervr based evil binaries (e.g. all cortex arm chips from TI) since there will be 2 providers of those libs. > > Why could one prefer providers of virtual/libgles2 and virtual/ligegl > on a per-machine basis. This maps quite well with the reality. Apart from the fact that both aren't machine specific. Making them machine specific would be a regression.
On 1 August 2012 15:54, Koen Kooi <koen@dominion.thruhere.net> wrote:
> Apart from the fact that both aren't machine specific. Making them machine specific would be a regression.
Theoretically, yes. Practically, only one of the libegl.so (libgl,
etc etc) actually works on a particular machine.
Ross
On 1 August 2012 15:54, Koen Kooi <koen@dominion.thruhere.net> wrote:
> That won't work with debian renaming and shlib will pick up both anyway. You can only have one libegl.so *ever* during the build.
In Debian the packages are renamed libgles2-mesa, and so on...
Ross
Op 1 aug. 2012, om 16:57 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven: > On 1 August 2012 15:54, Koen Kooi <koen@dominion.thruhere.net> wrote: >> Apart from the fact that both aren't machine specific. Making them machine specific would be a regression. > > Theoretically, yes. Practically, only one of the libegl.so (libgl, > etc etc) actually works on a particular machine. Yes, but a libegl.so works on a range of machines, not a single one.