What happens: * Mesa build system tries to use /usr/lib for the cross compilation (libexpat, libdl, libz, etc) * It is only for ARMv7 so far, aarch64 works as expected, my guess is that it has to do with the 64-64bit with 64-32bit of the host/target mismatch Workaround: /usr/armv7a-hardfloat-linux-gnueabi/etc/portage/make.conf # When host is 64bit and target 32bit, the `lib64` directory tend to leak # into the build LD_LIBRARY_PATH="/usr/armv7a-hardfloat-linux-gnueabi/lib:/usr/armv7a-hardfloat-linux-gnueabi/usr/lib/" LD_RUN_PATH="/usr/armv7a-hardfloat-linux-gnueabi/lib:/usr/armv7a-hardfloat-linux-gnueabi/usr/lib/" CFLAGS="-O2 -pipe -fomit-frame-pointer -L/usr/armv7a-hardfloat-linux-gnueabi/lib/ -L/usr/armv7a-hardfloat-linux-gnueabi/usr/lib/" With the above additions, it starts to work again. (I am mostly reporting this bug to document all issues I had creating my toolchain, I already reported a dozen or so, sorry for the noise)
may I ask, were you able to cross compile mesa with llvm useflag this way?
> may I ask, were you able to cross compile mesa with llvm useflag this way? I was using GCC the whole time. At the time I felt that its LTO and PGO support was still quite superior. LTO is very important for "bundled" cross-compiled binaries on ARM because it cuts the startup time by 80%.
this is not a Prefix bug, please take it up with the crossdev guys
