Created attachment 570372 [details] build.log mesa has libXrandr in DEPEND. Yet for some reason when I try to install it into cross build environment with the dependency is not installed: # armv7a-linux-gnueabihf-emerge -1v mesa These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] media-libs/mesa-19.0.0::gentoo to /usr/armv7a-linux-gnueabihf/ USE="classic dri3 egl gallium gbm gles2 llvm (-d3d9) -debug -gles1 (-libglvnd) (-lm_sensors) (-opencl) -osmesa -pax_kernel -pic (-selinux) -test -unwind (-vaapi) -valgrind (-vdpau) (-vulkan) -wayland -xa -xvmc" VIDEO_CARDS="-freedreno (-i915) (-i965) -imx (-intel) (-nouveau) (-r100) (-r200) (-r300) (-r600) (-radeon) (-radeonsi) -vc4 -virgl -vivante (-vmware)" 0 KiB (...) Cross dependency xrandr found: NO (tried pkgconfig) meson.build:1404:4: ERROR: Dependency "xrandr" not found, tried pkgconfig A full log can be found at /usr/armv7a-linux-gnueabihf/tmp/portage/media-libs/mesa-19.0.0/work/mesa-19.0.0-.arm/meson-logs/meson-log.txt
Created attachment 570374 [details] emerge-info.log
Created attachment 570376 [details] meson-log.txt
If I install libXrandr by hand, then media-libs/mesa is compiled and installed, of course (only with USE="-llvm" due to https://bugs.gentoo.org/662722 but that is another story).
Chewi, do you have any ideas?
EAPI 7 is needed for this to work.
(In reply to James Le Cuirot from comment #5) > EAPI 7 is needed for this to work. Okay, I don't know of any problems in migrating media-libs/mesa to EAPI=7. Can you explain to me what the problem is? (not with migrating, but the problem reported in this bug)
(In reply to Matt Turner from comment #6) > Can you explain to me what the problem is? (not with migrating, but the > problem reported in this bug) libXrandr is in DEPEND but not RDEPEND. Assuming this isn't a mistake, EAPI 6 and earlier will only install libXrandr to /. It may not even install it at all because crossdev's emerge wrapper automatically passes --root-deps=rdeps, which throws DEPEND away entirely, but that's a moot point here. It's not safe to use headers from / when cross-compiling so pkg-config doesn't look for the .pc file there. Under EAPI 7, DEPEND is installed to ROOT instead so the .pc file will be found and everything will work.
(In reply to James Le Cuirot from comment #7) > (In reply to Matt Turner from comment #6) > > Can you explain to me what the problem is? (not with migrating, but the > > problem reported in this bug) > libXrandr is in DEPEND but not RDEPEND. Assuming this isn't a mistake, EAPI > 6 and earlier will only install libXrandr to /. It may not even install it > at all because crossdev's emerge wrapper automatically passes > --root-deps=rdeps, which throws DEPEND away entirely, but that's a moot > point here. It's not safe to use headers from / when cross-compiling so > pkg-config doesn't look for the .pc file there. Under EAPI 7, DEPEND is > installed to ROOT instead so the .pc file will be found and everything will > work. Ah, interesting. Thanks for the explanation. I believe that DEPEND (and not RDEPEND) containing libXrandr is correct. I believe it only requires the headers, as I see that libvulkan_intel.so links with libxcb-randr.so.0 and not libXrandr.
Chewi, do you want to take the lead on this? I assume switching Mesa to EAPI=7 is all that's needed. The problems I've encountered in a quick attempt are: 1) llvm.eclass doesn't support EAPI=7 2) in python_check_deps() has_version no longer takes --host-root in EAPI=7.
(In reply to Matt Turner from comment #9) > Chewi, do you want to take the lead on this? I assume switching Mesa to > EAPI=7 is all that's needed. The problems I've encountered in a quick > attempt are: > > 1) llvm.eclass doesn't support EAPI=7 > 2) in python_check_deps() has_version no longer takes --host-root in EAPI=7. Matt already knows but for the benefit of anyone stumbling across this, mgorny and I looked into EAPI 7 support but there are cross-compile issues with LLVM that we haven't resolved yet.
Created attachment 579976 [details, diff] patch Chewi, how does this look? (I'm aware that LLVM cross compilation isn't likely to work, but that's tracked in bug 662722)
(In reply to Matt Turner from comment #11) > Created attachment 579976 [details, diff] [details, diff] > patch > > Chewi, how does this look? (I'm aware that LLVM cross compilation isn't > likely to work, but that's tracked in bug 662722) I added -d to the other has_version calls but I guess -r (the default) is equally correct in this case. Does "opencl? ( >=sys-devel/gcc-4.6 )" not belong in BDEPEND? I'm not sure how it's used.
(In reply to James Le Cuirot from comment #12) > (In reply to Matt Turner from comment #11) > > Created attachment 579976 [details, diff] [details, diff] [details, diff] > > patch > > > > Chewi, how does this look? (I'm aware that LLVM cross compilation isn't > > likely to work, but that's tracked in bug 662722) > > I added -d to the other has_version calls but I guess -r (the default) is > equally correct in this case. So... not -b? mako is used by some python scripts that run during the build process to generate C code that's then compiled. I figure that BDEPEND is the right place for such a dep, especially if $PYTHON_DEPS goes in BDEPEND. > Does "opencl? ( >=sys-devel/gcc-4.6 )" not belong in BDEPEND? I'm not sure > how it's used. Yes, thanks. Fixed locally.
(In reply to Matt Turner from comment #13) > (In reply to James Le Cuirot from comment #12) > > I added -d to the other has_version calls but I guess -r (the default) is > > equally correct in this case. > > So... not -b? mako is used by some python scripts that run during the build > process to generate C code that's then compiled. I figure that BDEPEND is > the right place for such a dep, especially if $PYTHON_DEPS goes in BDEPEND. -b for mako is fine but there are two more instances of has_version for LLVM and Clang. When I think about it in the context of my recent SYSROOT discussions, you should technically do it twice for each, once for DEPEND and once for RDEPEND because you don't want to build against one SLOT and then try to run against another. I wouldn't bother though because this is a much wider problem that even affects subslotted libraries. It would need to be fixed in Portage.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5d21ede9cbe72b989baaafb125a4a4e356d2fec1 commit 5d21ede9cbe72b989baaafb125a4a4e356d2fec1 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2019-06-17 14:24:14 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2019-06-19 16:37:25 +0000 media-libs/mesa: Port to EAPI=7 Closes: https://bugs.gentoo.org/681540 Signed-off-by: Matt Turner <mattst88@gentoo.org> media-libs/mesa/mesa-9999.ebuild | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
(In reply to James Le Cuirot from comment #14) > -b for mako is fine but there are two more instances of has_version for LLVM > and Clang. When I think about it in the context of my recent SYSROOT > discussions, you should technically do it twice for each, once for DEPEND > and once for RDEPEND because you don't want to build against one SLOT and > then try to run against another. I wouldn't bother though because this is a > much wider problem that even affects subslotted libraries. It would need to > be fixed in Portage. Thanks. We'll fix that up when it's possible to cross compile against llvm.
