[bitbake-devel] Two recipes providing the same .so... How it should not be done :)
Ricardo Ribalda Delgado
ricardo.ribalda at gmail.com
Fri Mar 1 11:28:11 UTC 2019
Hello
I have a build system that supports some aarch64 machines. For most of
the them, the only difference is the kernel configuration, kernel
version.
I am using multiconfig on my build server and the build goes really
fast thanks to all the shared binaries/artifacts.
But I have a problem adding a new machine. This machine is also
aarch64, with a special kernel (nothing new here), but in this case
the vendor provides a binary .so for libgl that is required to get
hardware acceleation.
I could .bbappend mesa and on the installation part replace libgl with
the new .so. But then everything that depends on mesa needs to be
rebuilt for that machine and I could not use multiconfig.
Instead I have created a new recipe: mesa-gl-replace.bb that has the
file. This breakes completely the design of OE, but works.
Some snipsets of the "magic" to make it work:
#Force that the version is allways higher than the one from mesa:
PE = "5"
#Rprovide the same as mesa
RPROVIDES_libgl-mesa += "libgl"
#Do not overwrite pkgdata of mesa
PACKAGEFUNCS_append = " rm_pkgdata_runtime"
rm_pkgdata_runtime() {
rm -rf ${WORKDIR}/pkgdata/runtime/*
rm -rf ${WORKDIR}/pkgdata/shlibs2/*
}
#Keep this on machine
PACKAGE_ARCH = "${MACHINE_ARCH}"
#Make sure we are not saved as providers for libgl
PRIVATE_LIBS = "libGL.so.1"
#Avoid sanity checks
read_subpackage_metadata () {
}
If your eyes have not fallen as this point, this means you have a lot
of tolerance for crappy code, congrats :)
Now the question. Is there a better way to do this?
PS: I already tried and failed with update_alternatives
Best regards!
--
Ricardo Ribalda
More information about the bitbake-devel
mailing list