* Mesa mess
@ 2013-10-23 13:43 Gary Thomas
2013-10-23 14:07 ` Burton, Ross
0 siblings, 1 reply; 9+ messages in thread
From: Gary Thomas @ 2013-10-23 13:43 UTC (permalink / raw)
To: OE-core
With the current master (Poky ffb440c37c), I can't build anything
with a virtual/mesa requirement. This seems to bring in both mesa
and mesa-gl, which fight to the death, killing the build :-(
It starts with this error:
ERROR: Multiple .bb files are due to be built which each provide virtual/libgl (/local/poky-cutting-edge/meta/recipes-graphics/mesa/mesa_9.1.6.bb
/local/poky-cutting-edge/meta/recipes-graphics/mesa/mesa-gl_9.1.6.bb).
This usually means one provides something the other doesn't and should.
And ends when mesa tries to reset the PR:
ERROR: Recipe mesa is trying to change PR from 'r1' to 'r0'. This will cause do_package_write_* failures since the incorrect data will be used and they will be unable to find
the right workdir.
I'm using my own distro based on Poky, with these features enabled:
DISTRO_FEATURES="sysvinit alsa ipv4 x11 opengl wifi ext2 largefile ipv4 ipv6 libc-backtrace libc-big-macros libc-bsd libc-cxx-tests libc-catgets libc-charsets libc-crypt
libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt libc-fmtmsg libc-fstab libc-ftraverse libc-getlogin libc-idn
libc-inet-anl libc-libm libc-locales libc-locale-code libc-memusage libc-nis libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn libc-streams
libc-sunrpc libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar libc-posix-regexp libc-posix-regexp-glibc
libc-posix-wchar-io pulseaudio"
How can I get past this error?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Mesa mess 2013-10-23 13:43 Mesa mess Gary Thomas @ 2013-10-23 14:07 ` Burton, Ross 2013-10-23 17:13 ` Gary Thomas 0 siblings, 1 reply; 9+ messages in thread From: Burton, Ross @ 2013-10-23 14:07 UTC (permalink / raw) To: Gary Thomas; +Cc: OE-core On 23 October 2013 14:43, Gary Thomas <gary@mlbassoc.com> wrote: > With the current master (Poky ffb440c37c), I can't build anything > with a virtual/mesa requirement. This seems to bring in both mesa > and mesa-gl, which fight to the death, killing the build :-( Presumably you want just mesa-gl? I guess your distro is setting a preferred provider for virtual/something to mesa-gl, and something else is pulling in mesa, probably through a default. Can you check that all of the mesa-related virtual/* lines are set in your distro, my hunch is that you don't have virtual/mesa set to mesa-gl. If the distro looks right then try using depexp to see what is pulling in mesa when it shouldn't be? Ross ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mesa mess 2013-10-23 14:07 ` Burton, Ross @ 2013-10-23 17:13 ` Gary Thomas 2013-10-23 17:18 ` Gary Thomas 0 siblings, 1 reply; 9+ messages in thread From: Gary Thomas @ 2013-10-23 17:13 UTC (permalink / raw) To: Burton, Ross; +Cc: OE-core On 2013-10-23 08:07, Burton, Ross wrote: > On 23 October 2013 14:43, Gary Thomas <gary@mlbassoc.com> wrote: >> With the current master (Poky ffb440c37c), I can't build anything >> with a virtual/mesa requirement. This seems to bring in both mesa >> and mesa-gl, which fight to the death, killing the build :-( > > Presumably you want just mesa-gl? > > I guess your distro is setting a preferred provider for > virtual/something to mesa-gl, and something else is pulling in mesa, > probably through a default. Can you check that all of the > mesa-related virtual/* lines are set in your distro, my hunch is that > you don't have virtual/mesa set to mesa-gl. > > If the distro looks right then try using depexp to see what is pulling > in mesa when it shouldn't be? I looked through this and nothing was obvious. According to depmod, neither mesa nor mesa-gl have any direct "reverse depends", i.e. packages that depend on them. As far as I can see, it's just coming from the xserver-xorg dependency on virtual/mesa. Which led me to another experiment which I truly do not understand. I removed the mesa-gl recipe and now when I try to build 'virtual/mesa' I get a message that there is no provider :-( However, I *can* build mesa with no problems. I also checked it against the other PROVIDES from mesa.inc and all of them except for virtual/mesa work. How can this possibly be? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mesa mess 2013-10-23 17:13 ` Gary Thomas @ 2013-10-23 17:18 ` Gary Thomas 2013-10-24 0:57 ` Gary Thomas 0 siblings, 1 reply; 9+ messages in thread From: Gary Thomas @ 2013-10-23 17:18 UTC (permalink / raw) To: Burton, Ross; +Cc: OE-core On 2013-10-23 11:13, Gary Thomas wrote: > On 2013-10-23 08:07, Burton, Ross wrote: >> On 23 October 2013 14:43, Gary Thomas <gary@mlbassoc.com> wrote: >>> With the current master (Poky ffb440c37c), I can't build anything >>> with a virtual/mesa requirement. This seems to bring in both mesa >>> and mesa-gl, which fight to the death, killing the build :-( >> >> Presumably you want just mesa-gl? >> >> I guess your distro is setting a preferred provider for >> virtual/something to mesa-gl, and something else is pulling in mesa, >> probably through a default. Can you check that all of the >> mesa-related virtual/* lines are set in your distro, my hunch is that >> you don't have virtual/mesa set to mesa-gl. I also compared all of the PREFERRED_PROVIDERs between my build and a stock poky build and they are identical. >> >> If the distro looks right then try using depexp to see what is pulling >> in mesa when it shouldn't be? > > I looked through this and nothing was obvious. According to depmod, neither > mesa nor mesa-gl have any direct "reverse depends", i.e. packages that depend > on them. As far as I can see, it's just coming from the xserver-xorg dependency > on virtual/mesa. > > Which led me to another experiment which I truly do not understand. I removed > the mesa-gl recipe and now when I try to build 'virtual/mesa' I get a message > that there is no provider :-( However, I *can* build mesa with no problems. > I also checked it against the other PROVIDES from mesa.inc and all of them > except for virtual/mesa work. How can this possibly be? To be clear, 'bitbake virtual/libgl' (or any of its friends except virtual/mesa) will cause 'mesa' to be built, but 'bitbake virtual/mesa' fails. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mesa mess 2013-10-23 17:18 ` Gary Thomas @ 2013-10-24 0:57 ` Gary Thomas 2013-10-24 7:43 ` Andreas Müller 2013-10-28 14:54 ` Burton, Ross 0 siblings, 2 replies; 9+ messages in thread From: Gary Thomas @ 2013-10-24 0:57 UTC (permalink / raw) To: Burton, Ross; +Cc: OE-core On 2013-10-23 11:18, Gary Thomas wrote: > On 2013-10-23 11:13, Gary Thomas wrote: >> On 2013-10-23 08:07, Burton, Ross wrote: >>> On 23 October 2013 14:43, Gary Thomas <gary@mlbassoc.com> wrote: >>>> With the current master (Poky ffb440c37c), I can't build anything >>>> with a virtual/mesa requirement. This seems to bring in both mesa >>>> and mesa-gl, which fight to the death, killing the build :-( >>> >>> Presumably you want just mesa-gl? >>> >>> I guess your distro is setting a preferred provider for >>> virtual/something to mesa-gl, and something else is pulling in mesa, >>> probably through a default. Can you check that all of the >>> mesa-related virtual/* lines are set in your distro, my hunch is that >>> you don't have virtual/mesa set to mesa-gl. > > I also compared all of the PREFERRED_PROVIDERs between my build and a stock > poky build and they are identical. > >>> >>> If the distro looks right then try using depexp to see what is pulling >>> in mesa when it shouldn't be? >> >> I looked through this and nothing was obvious. According to depmod, neither >> mesa nor mesa-gl have any direct "reverse depends", i.e. packages that depend >> on them. As far as I can see, it's just coming from the xserver-xorg dependency >> on virtual/mesa. >> >> Which led me to another experiment which I truly do not understand. I removed >> the mesa-gl recipe and now when I try to build 'virtual/mesa' I get a message >> that there is no provider :-( However, I *can* build mesa with no problems. >> I also checked it against the other PROVIDES from mesa.inc and all of them >> except for virtual/mesa work. How can this possibly be? > > To be clear, 'bitbake virtual/libgl' (or any of its friends except virtual/mesa) > will cause 'mesa' to be built, but 'bitbake virtual/mesa' fails. > I found the cause :-) In addition to OE-core, I am using meta-ti on an OMAP3 target. In meta-ti, there is this line: meta-ti/recipes-graphics/mesa/mesa-omap3-common.inc:PROVIDES_omap3 = "virtual/libgl" I added virtual/mesa to this list and it now builds again. I'm not sure that this is 100% correct though. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mesa mess 2013-10-24 0:57 ` Gary Thomas @ 2013-10-24 7:43 ` Andreas Müller 2013-10-24 8:58 ` Andreas Müller 2013-10-28 14:54 ` Burton, Ross 1 sibling, 1 reply; 9+ messages in thread From: Andreas Müller @ 2013-10-24 7:43 UTC (permalink / raw) To: Gary Thomas; +Cc: meta-ti, OE-core On Thu, Oct 24, 2013 at 2:57 AM, Gary Thomas <gary@mlbassoc.com> wrote: > On 2013-10-23 11:18, Gary Thomas wrote: >> >> On 2013-10-23 11:13, Gary Thomas wrote: >>> >>> On 2013-10-23 08:07, Burton, Ross wrote: >>>> >>>> On 23 October 2013 14:43, Gary Thomas <gary@mlbassoc.com> wrote: >>>>> >>>>> With the current master (Poky ffb440c37c), I can't build anything >>>>> with a virtual/mesa requirement. This seems to bring in both mesa >>>>> and mesa-gl, which fight to the death, killing the build :-( >>>> >>>> >>>> Presumably you want just mesa-gl? >>>> >>>> I guess your distro is setting a preferred provider for >>>> virtual/something to mesa-gl, and something else is pulling in mesa, >>>> probably through a default. Can you check that all of the >>>> mesa-related virtual/* lines are set in your distro, my hunch is that >>>> you don't have virtual/mesa set to mesa-gl. >> >> >> I also compared all of the PREFERRED_PROVIDERs between my build and a >> stock >> poky build and they are identical. >> >>>> >>>> If the distro looks right then try using depexp to see what is pulling >>>> in mesa when it shouldn't be? >>> >>> >>> I looked through this and nothing was obvious. According to depmod, >>> neither >>> mesa nor mesa-gl have any direct "reverse depends", i.e. packages that >>> depend >>> on them. As far as I can see, it's just coming from the xserver-xorg >>> dependency >>> on virtual/mesa. >>> >>> Which led me to another experiment which I truly do not understand. I >>> removed >>> the mesa-gl recipe and now when I try to build 'virtual/mesa' I get a >>> message >>> that there is no provider :-( However, I *can* build mesa with no >>> problems. >>> I also checked it against the other PROVIDES from mesa.inc and all of >>> them >>> except for virtual/mesa work. How can this possibly be? >> >> >> To be clear, 'bitbake virtual/libgl' (or any of its friends except >> virtual/mesa) >> will cause 'mesa' to be built, but 'bitbake virtual/mesa' fails. >> > > I found the cause :-) In addition to OE-core, I am using meta-ti on an > OMAP3 target. > In meta-ti, there is this line: > meta-ti/recipes-graphics/mesa/mesa-omap3-common.inc:PROVIDES_omap3 = > "virtual/libgl" > I added virtual/mesa to this list and it now builds again. I'm not sure > that this is > 100% correct though. > > I am struggling for the same issue and removed the PROVIDES because they are not correct any more: for omap3 we need mesa-gl as PROVIDER for libgl. Same for virtual/mesa. But still: Seems something is broken with virtual/libgl*. I working on a bsp-layer [1] and maybe I did something wrong there but building virtual/libgles2 builds mesa whatever I try... Andreas [1] git://gitorious.org/schnitzeltony-oe-meta/meta-toradex-community.git ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mesa mess 2013-10-24 7:43 ` Andreas Müller @ 2013-10-24 8:58 ` Andreas Müller 0 siblings, 0 replies; 9+ messages in thread From: Andreas Müller @ 2013-10-24 8:58 UTC (permalink / raw) To: Gary Thomas; +Cc: meta-ti, OE-core On Thu, Oct 24, 2013 at 9:43 AM, Andreas Müller <schnitzeltony@googlemail.com> wrote: > On Thu, Oct 24, 2013 at 2:57 AM, Gary Thomas <gary@mlbassoc.com> wrote: >> On 2013-10-23 11:18, Gary Thomas wrote: >>> >>> On 2013-10-23 11:13, Gary Thomas wrote: >>>> >>>> On 2013-10-23 08:07, Burton, Ross wrote: >>>>> >>>>> On 23 October 2013 14:43, Gary Thomas <gary@mlbassoc.com> wrote: >>>>>> >>>>>> With the current master (Poky ffb440c37c), I can't build anything >>>>>> with a virtual/mesa requirement. This seems to bring in both mesa >>>>>> and mesa-gl, which fight to the death, killing the build :-( >>>>> >>>>> >>>>> Presumably you want just mesa-gl? >>>>> >>>>> I guess your distro is setting a preferred provider for >>>>> virtual/something to mesa-gl, and something else is pulling in mesa, >>>>> probably through a default. Can you check that all of the >>>>> mesa-related virtual/* lines are set in your distro, my hunch is that >>>>> you don't have virtual/mesa set to mesa-gl. >>> >>> >>> I also compared all of the PREFERRED_PROVIDERs between my build and a >>> stock >>> poky build and they are identical. >>> >>>>> >>>>> If the distro looks right then try using depexp to see what is pulling >>>>> in mesa when it shouldn't be? >>>> >>>> >>>> I looked through this and nothing was obvious. According to depmod, >>>> neither >>>> mesa nor mesa-gl have any direct "reverse depends", i.e. packages that >>>> depend >>>> on them. As far as I can see, it's just coming from the xserver-xorg >>>> dependency >>>> on virtual/mesa. >>>> >>>> Which led me to another experiment which I truly do not understand. I >>>> removed >>>> the mesa-gl recipe and now when I try to build 'virtual/mesa' I get a >>>> message >>>> that there is no provider :-( However, I *can* build mesa with no >>>> problems. >>>> I also checked it against the other PROVIDES from mesa.inc and all of >>>> them >>>> except for virtual/mesa work. How can this possibly be? >>> >>> >>> To be clear, 'bitbake virtual/libgl' (or any of its friends except >>> virtual/mesa) >>> will cause 'mesa' to be built, but 'bitbake virtual/mesa' fails. >>> >> >> I found the cause :-) In addition to OE-core, I am using meta-ti on an >> OMAP3 target. >> In meta-ti, there is this line: >> meta-ti/recipes-graphics/mesa/mesa-omap3-common.inc:PROVIDES_omap3 = >> "virtual/libgl" >> I added virtual/mesa to this list and it now builds again. I'm not sure >> that this is >> 100% correct though. >> >> > I am struggling for the same issue and removed the PROVIDES because > they are not correct any more: for omap3 we need mesa-gl as PROVIDER > for libgl. Same for virtual/mesa. > > But still: Seems something is broken with virtual/libgl*. I working on > a bsp-layer [1] and maybe I did something wrong there but building > virtual/libgles2 builds mesa whatever I try... > > Andreas > > [1] git://gitorious.org/schnitzeltony-oe-meta/meta-toradex-community.git I added PREFERRED_PROVIDER for all virtual/libgl* and virtual/mesa in machine config and am fine now. Andreas ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mesa mess 2013-10-24 0:57 ` Gary Thomas 2013-10-24 7:43 ` Andreas Müller @ 2013-10-28 14:54 ` Burton, Ross 2013-10-28 14:57 ` Gary Thomas 1 sibling, 1 reply; 9+ messages in thread From: Burton, Ross @ 2013-10-28 14:54 UTC (permalink / raw) To: Gary Thomas; +Cc: OE-core On 24 October 2013 01:57, Gary Thomas <gary@mlbassoc.com> wrote: > I found the cause :-) In addition to OE-core, I am using meta-ti on an > OMAP3 target. > In meta-ti, there is this line: > meta-ti/recipes-graphics/mesa/mesa-omap3-common.inc:PROVIDES_omap3 = > "virtual/libgl" > I added virtual/mesa to this list and it now builds again. I'm not sure > that this is > 100% correct though. That's correct - did you send a patch to meta-ti? Ross ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mesa mess 2013-10-28 14:54 ` Burton, Ross @ 2013-10-28 14:57 ` Gary Thomas 0 siblings, 0 replies; 9+ messages in thread From: Gary Thomas @ 2013-10-28 14:57 UTC (permalink / raw) To: Burton, Ross; +Cc: OE-core On 2013-10-28 08:54, Burton, Ross wrote: > On 24 October 2013 01:57, Gary Thomas <gary@mlbassoc.com> wrote: >> I found the cause :-) In addition to OE-core, I am using meta-ti on an >> OMAP3 target. >> In meta-ti, there is this line: >> meta-ti/recipes-graphics/mesa/mesa-omap3-common.inc:PROVIDES_omap3 = >> "virtual/libgl" >> I added virtual/mesa to this list and it now builds again. I'm not sure >> that this is >> 100% correct though. > > That's correct - did you send a patch to meta-ti? There was a discussion about this on meta-ti and it was decided to fix it (rather drastically by removing these overrides) when the core mesa recipe is upgraded (already proposed). -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-10-28 14:57 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-10-23 13:43 Mesa mess Gary Thomas 2013-10-23 14:07 ` Burton, Ross 2013-10-23 17:13 ` Gary Thomas 2013-10-23 17:18 ` Gary Thomas 2013-10-24 0:57 ` Gary Thomas 2013-10-24 7:43 ` Andreas Müller 2013-10-24 8:58 ` Andreas Müller 2013-10-28 14:54 ` Burton, Ross 2013-10-28 14:57 ` Gary Thomas
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox