[bitbake-devel] [OE-core] Two recipes providing the same .so... How it should not be done :)

[Burton, Ross]

Does they literally just provide a libgl.so and no headers, etc?

Ross

On Fri, 1 Mar 2019 at 11:29, Ricardo Ribalda Delgado
<ricardo.ribalda at gmail.com> wrote:
>
> 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
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core