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

[Burton, Ross]

That is horrible and they should be ashamed.  Can you share the
complete recipe, as this *should* be a fairly trivial switcharoony.

Ross

On Tue, 5 Mar 2019 at 11:00, Ricardo Ribalda Delgado
<ricardo.ribalda at gmail.com> wrote:
>
> HI Ross
> On Tue, Mar 5, 2019 at 11:58 AM Burton, Ross <ross.burton at intel.com> wrote:
> >
> > Does they literally just provide a libgl.so and no headers, etc?
>
> It provides:
>
> /usr/lib/libGL.so.1.2.0
> /usr/lib/libGL.so.1
>
>
> >
> > 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
>
>
>
> --
> Ricardo Ribalda