[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