Mesa mess
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?
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 3 lines · Gary Thomas
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
Quoted 7 lines · Ross
Quoted 3 lines · Gary Thomas
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?
Quoted 8 lines
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?
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 6 lines · Gary Thomas
Quoted 5 lines · Ross
Quoted 3 lines · Gary Thomas
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 :-(
Quoted 7 lines
Quoted 7 lines
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.
Quoted 9 lines
Quoted 3 lines
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.
Quoted 5 lines
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.
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 27 lines · Gary Thomas
Quoted 6 lines · Gary Thomas
Quoted 5 lines · Ross
Quoted 3 lines · Gary Thomas
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 :-(Quoted 7 lines
Quoted 7 lines
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_PROVIDERsbetween my build and a stock poky build and they are identical.Quoted 9 lines
Quoted 3 lines
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.
Quoted 9 lines
Quoted 5 lines
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.
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 55 lines · Gary Thomas
Quoted 49 lines · Gary Thomas
Quoted 10 lines · Gary Thomas
Quoted 8 lines · Ross
Quoted 4 lines · Gary Thomas
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 :-(Quoted 7 lines
Quoted 7 lines
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_PROVIDERsbetween my build and a stock
poky build and they are identical.Quoted 13 lines
Quoted 3 lines
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.Quoted 9 lines
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?Quoted 4 lines
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.
Quoted 10 lines
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
Quoted 70 lines · Andreas Müller
Quoted 55 lines · Gary Thomas
Quoted 49 lines · Gary Thomas
Quoted 10 lines · Gary Thomas
Quoted 8 lines · Ross
Quoted 4 lines · Gary Thomas
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 :-(Quoted 7 lines
Quoted 7 lines
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_PROVIDERsbetween my build and a stock
poky build and they are identical.Quoted 13 lines
Quoted 3 lines
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.Quoted 9 lines
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?Quoted 4 lines
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.Quoted 10 lines
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.
Quoted 7 lines
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
Quoted 8 lines · Gary Thomas
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
Quoted 11 lines · Ross
Quoted 8 lines · Gary Thomas
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).
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------