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

[Ricardo Ribalda Delgado]

Hi Richard,

Thanks for your reply!

I tried with the following:

INSANE_SKIP_${PN} = "already-stripped"
INSANE_SKIP_libegl-tegra = "ldflags dev-so"
INSANE_SKIP_libgles1-tegra = "ldflags dev-so"
INSANE_SKIP_libgles2-tegra = "ldflags"
INSANE_SKIP_libgl-tegra = "ldflags dev-so textrel"

RREPLACES_libgl-tegra = "libgl-mesa"
RREPLACES_libegl-tegra = "libegl-mesa"
RREPLACES_libgles1-tegra = "libgles1-mesa"
RREPLACES_libgles2-tegra = "libgles2-mesa"

RCONFLICTS_libgl-tegra = "libgl-mesa"
RCONFLICTS_libegl-tegra = "libegl-mesa"
RCONFLICTS_libgles1-tegra = "libgles1-mesa"
RCONFLICTS_libgles2-tegra = "libgles2-mesa"

RPROVIDES_libgl-tegra += "gl-proprietary libgl libgl-mesa"
RPROVIDES_libegl-tegra += "libegl libegl-mesa"
RPROVIDES_libgles2-tegra += "libgles2 libgles2-tegra"
RPROVIDES_libgles1-tegra += "libgles1 libgles1-tegra"

But then do_rootfs fails:

The following packages have unmet dependencies:
 mesa-demos : Depends: libegl-mesa (>= 18.3.4+git0+b26488dead) but it
is not going to be installed
              Depends: libgl-mesa (>= 18.3.4+git0+b26488dead) but it
is not going to be installed
 qv4l2 : Depends: libgl-mesa (>= 18.3.4+git0+b26488dead) but it is not
going to be installed
         Depends: qtbase (>= 5.11.1+git0+74305ba470) but it is not
going to be installed


I am forcing the installation of libgl-tegra by making:

XSERVER += "gl-proprietary"

What am I doing wrong :)

Thanks!

On Sat, Mar 2, 2019 at 1:21 PM Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
>
> On Fri, 2019-03-01 at 12:28 +0100, Ricardo Ribalda Delgado 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?
>
> I'd probably let mesa build as normal but then add a recipe which
> RRPROVIDES, RREPLACES and RCONFLICTS with the specific mesa package you
> want to replace. It would create and equivalent package with the right
> contents and make it machine specific.
>
> There should be more variables like PRIVATE_LIBS which stop you having
> to use the more horrible hacks (INSANE_SKIP_*?).
>
> You might then only have the issue of ensuring this machine specific
> package gets installed into the images which need GL (or just install
> it in all images for that machine).
>
> Cheers,
>
> Richard
>


-- 
Ricardo Ribalda