* Two recipes providing the same .so... How it should not be done :)
@ 2019-03-01 11:28 Ricardo Ribalda Delgado
2019-03-02 12:21 ` Richard Purdie
2019-03-05 10:58 ` Burton, Ross
0 siblings, 2 replies; 18+ messages in thread
From: Ricardo Ribalda Delgado @ 2019-03-01 11:28 UTC (permalink / raw)
To: openembedded-core, Daniel Gomez, bitbake-devel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core] Two recipes providing the same .so... How it should not be done :)
2019-03-01 11:28 Two recipes providing the same .so... How it should not be done :) Ricardo Ribalda Delgado
@ 2019-03-02 12:21 ` Richard Purdie
2019-03-05 10:58 ` Burton, Ross
1 sibling, 0 replies; 18+ messages in thread
From: Richard Purdie @ 2019-03-02 12:21 UTC (permalink / raw)
To: Ricardo Ribalda Delgado, openembedded-core, Daniel Gomez, bitbake-devel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Two recipes providing the same .so... How it should not be done :)
@ 2019-03-02 12:21 ` Richard Purdie
0 siblings, 0 replies; 18+ messages in thread
From: Richard Purdie @ 2019-03-02 12:21 UTC (permalink / raw)
To: Ricardo Ribalda Delgado, openembedded-core, Daniel Gomez, bitbake-devel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Two recipes providing the same .so... How it should not be done :)
2019-03-02 12:21 ` Richard Purdie
(?)
@ 2019-03-05 8:27 ` Ricardo Ribalda Delgado
2019-03-05 9:37 ` Richard Purdie
-1 siblings, 1 reply; 18+ messages in thread
From: Ricardo Ribalda Delgado @ 2019-03-05 8:27 UTC (permalink / raw)
To: Richard Purdie; +Cc: Daniel Gomez, openembedded-core
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@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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Two recipes providing the same .so... How it should not be done :)
2019-03-05 8:27 ` Ricardo Ribalda Delgado
@ 2019-03-05 9:37 ` Richard Purdie
2019-03-05 10:51 ` Ricardo Ribalda Delgado
0 siblings, 1 reply; 18+ messages in thread
From: Richard Purdie @ 2019-03-05 9:37 UTC (permalink / raw)
To: Ricardo Ribalda Delgado; +Cc: Daniel Gomez, openembedded-core
On Tue, 2019-03-05 at 09:27 +0100, Ricardo Ribalda Delgado wrote:
> 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 :)
I'd forgotten that things have hard version requirements in some of
these dependencies :(
You'd probably need to make sure your recipe has a version (or epoch,
PE may be easier) higher than the original recipe? I think that is what
the package manager is saying in the error above.
Cheers,
Richard
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Two recipes providing the same .so... How it should not be done :)
2019-03-05 9:37 ` Richard Purdie
@ 2019-03-05 10:51 ` Ricardo Ribalda Delgado
0 siblings, 0 replies; 18+ messages in thread
From: Ricardo Ribalda Delgado @ 2019-03-05 10:51 UTC (permalink / raw)
To: Richard Purdie; +Cc: Daniel Gomez, openembedded-core
Epoch is set to 5, so that should not be the issue
PV = "${L4T_RELEASE}"
PE = "5"
Thanks
On Tue, Mar 5, 2019 at 10:37 AM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Tue, 2019-03-05 at 09:27 +0100, Ricardo Ribalda Delgado wrote:
> > 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 :)
>
> I'd forgotten that things have hard version requirements in some of
> these dependencies :(
>
> You'd probably need to make sure your recipe has a version (or epoch,
> PE may be easier) higher than the original recipe? I think that is what
> the package manager is saying in the error above.
>
> Cheers,
>
> Richard
>
--
Ricardo Ribalda
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core] Two recipes providing the same .so... How it should not be done :)
2019-03-01 11:28 Two recipes providing the same .so... How it should not be done :) Ricardo Ribalda Delgado
@ 2019-03-05 10:58 ` Burton, Ross
2019-03-05 10:58 ` Burton, Ross
1 sibling, 0 replies; 18+ messages in thread
From: Burton, Ross @ 2019-03-05 10:58 UTC (permalink / raw)
To: Ricardo Ribalda Delgado; +Cc: Daniel Gomez, bitbake-devel, openembedded-core
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@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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Two recipes providing the same .so... How it should not be done :)
@ 2019-03-05 10:58 ` Burton, Ross
0 siblings, 0 replies; 18+ messages in thread
From: Burton, Ross @ 2019-03-05 10:58 UTC (permalink / raw)
To: Ricardo Ribalda Delgado; +Cc: Daniel Gomez, bitbake-devel, openembedded-core
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@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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core] Two recipes providing the same .so... How it should not be done :)
2019-03-05 10:58 ` Burton, Ross
@ 2019-03-05 11:00 ` Ricardo Ribalda Delgado
-1 siblings, 0 replies; 18+ messages in thread
From: Ricardo Ribalda Delgado @ 2019-03-05 11:00 UTC (permalink / raw)
To: Burton, Ross; +Cc: Daniel Gomez, bitbake-devel, openembedded-core
HI Ross
On Tue, Mar 5, 2019 at 11:58 AM Burton, Ross <ross.burton@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@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@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Ricardo Ribalda
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Two recipes providing the same .so... How it should not be done :)
@ 2019-03-05 11:00 ` Ricardo Ribalda Delgado
0 siblings, 0 replies; 18+ messages in thread
From: Ricardo Ribalda Delgado @ 2019-03-05 11:00 UTC (permalink / raw)
To: Burton, Ross; +Cc: Daniel Gomez, bitbake-devel, openembedded-core
HI Ross
On Tue, Mar 5, 2019 at 11:58 AM Burton, Ross <ross.burton@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@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@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Ricardo Ribalda
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core] Two recipes providing the same .so... How it should not be done :)
2019-03-05 11:00 ` Ricardo Ribalda Delgado
@ 2019-03-05 11:06 ` Burton, Ross
-1 siblings, 0 replies; 18+ messages in thread
From: Burton, Ross @ 2019-03-05 11:06 UTC (permalink / raw)
To: Ricardo Ribalda Delgado; +Cc: Daniel Gomez, bitbake-devel, openembedded-core
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@gmail.com> wrote:
>
> HI Ross
> On Tue, Mar 5, 2019 at 11:58 AM Burton, Ross <ross.burton@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@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@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
> --
> Ricardo Ribalda
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Two recipes providing the same .so... How it should not be done :)
@ 2019-03-05 11:06 ` Burton, Ross
0 siblings, 0 replies; 18+ messages in thread
From: Burton, Ross @ 2019-03-05 11:06 UTC (permalink / raw)
To: Ricardo Ribalda Delgado; +Cc: Daniel Gomez, bitbake-devel, openembedded-core
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@gmail.com> wrote:
>
> HI Ross
> On Tue, Mar 5, 2019 at 11:58 AM Burton, Ross <ross.burton@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@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@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
> --
> Ricardo Ribalda
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core] Two recipes providing the same .so... How it should not be done :)
2019-03-05 11:06 ` Burton, Ross
@ 2019-03-05 11:09 ` Ricardo Ribalda Delgado
-1 siblings, 0 replies; 18+ messages in thread
From: Ricardo Ribalda Delgado @ 2019-03-05 11:09 UTC (permalink / raw)
To: Burton, Ross; +Cc: Daniel Gomez, bitbake-devel, openembedded-core
This is my approach (which is not more than a horrible hack)
DESCRIPTION = "Tegra replacements for mesa libraries"
require recipes-bsp/tegra-binaries/tegra-glvnd.inc
RDEPENDS_libgl-mesa = "tegra-lib-common libegl-mesa libxcb-glx
libxxf86vm libxdamage libxcb-xfixes"
RDEPENDS_libegl-mesa = "zlib libxcb-xfixes libxcb-present libdrm
libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
libx11 libx11-xcb"
RDEPENDS_libgles2-mesa = "libdrm libglapi"
RDEPENDS_libgles1-mesa = "libdrm libglapi"
RPROVIDES_libgl-mesa += "gl-proprietary libgl"
RPROVIDES_libegl-mesa += "libegl"
RPROVIDES_libgles2-mesa += "libgles2"
RPROVIDES_libgles1-mesa += "libgles1"
PV = "${L4T_RELEASE}"
PE = "5"
PACKAGES = "libgl-mesa libegl-mesa libgles2-mesa libgles1-mesa"
L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"
do_unpack_append() {
bb.build.exec_func("unpack_l4t_tar", d)
}
unpack_l4t_tar() {
install -d ${L4T_GLVND_DIR}
tar -C ${L4T_GLVND_DIR} -x -f \
${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
usr/lib/aarch64-linux-gnu/tegra \
usr/lib/aarch64-linux-gnu/tegra-egl
}
do_compile[noexec] = "1"
PACKAGEFUNCS_append = " rm_pkgdata_runtime"
rm_pkgdata_runtime() {
rm -rf ${WORKDIR}/pkgdata/runtime/*
rm -rf ${WORKDIR}/pkgdata/shlibs2/*
}
do_install() {
install -d ${D}${libdir}
# Install NVIDIA mesa libraries (libglvnd)
install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 ${D}${libdir}/libGL.so.1.2.0
install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 ${D}${libdir}/libEGL.so.1.0.0
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
${D}${libdir}/libGLESv1_CM.so.1.1.0
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
${D}${libdir}/libGLESv2.so.2.0.0
ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2
# Install extra NVIDIA libglvnd libraries
install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so
# Install extra EGL NVIDIA libraries
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 ${D}${libdir}/
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/
# Install extra GL NVIDIA libraries
install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/
# Install libraries dependent on libglvnd libs
install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so
install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/
# nvcamera_daemon and argus_daemon have hard-coded path for this
install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
ln -sf ${libdir}/libEGL.so.1.0.0
${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so
}
PACKAGE_ARCH = "${MACHINE_ARCH}"
FILES_libgles1-mesa += "\
${libdir}/libGLESv1* \
"
FILES_libgles2-mesa += "\
${libdir}/libGLESv2* \
"
FILES_libegl-mesa += "\
${libdir}/libEGL* \
${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so \
"
FILES_libgl-mesa += "\
${libdir}/libGL.* \
${libdir}/libGLX* \
${libdir}/libGLdispatch.so* \
${libdir}/libnvidia-glsi.so.28.2.1 \
${libdir}/libnvbuf_utils.so* \
${libdir}/libnvddk_vic.so \
${libdir}/libnvddk_2d_v2.so \
"
INSANE_SKIP_${PN} = "already-stripped"
INSANE_SKIP_libegl-mesa = "ldflags dev-so"
INSANE_SKIP_libgles1-mesa = "ldflags dev-so"
INSANE_SKIP_libgles2-mesa = "ldflags"
INSANE_SKIP_libgl-mesa = "ldflags dev-so textrel"
PRIVATE_LIBS = "libGL.so.1 libEGL.so.1 libGLESv2.so.2 libGLESv1_CM.so.1"
read_subpackage_metadata () {
}
This is as Richard suggested:
DESCRIPTION = "Tegra replacements for mesa libraries"
require recipes-bsp/tegra-binaries/tegra-glvnd.inc
RDEPENDS_libgl-tegra = "tegra-lib-common libegl-tegra libxcb-glx
libxxf86vm libxdamage libxcb-xfixes"
RDEPENDS_libegl-tegra = "zlib libxcb-xfixes libxcb-present libdrm
libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
libx11 libx11-xcb"
RDEPENDS_libgles2-tegra = "libdrm libglapi"
RDEPENDS_libgles1-tegra = "libdrm libglapi"
PV = "${L4T_RELEASE}"
PE = "5"
PACKAGES = "libgl-tegra libegl-tegra libgles2-tegra libgles1-tegra"
L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"
do_unpack_append() {
bb.build.exec_func("unpack_l4t_tar", d)
}
unpack_l4t_tar() {
install -d ${L4T_GLVND_DIR}
tar -C ${L4T_GLVND_DIR} -x -f \
${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
usr/lib/aarch64-linux-gnu/tegra \
usr/lib/aarch64-linux-gnu/tegra-egl
}
do_compile[noexec] = "1"
do_install() {
install -d ${D}${libdir}
# Install NVIDIA mesa libraries (libglvnd)
install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 ${D}${libdir}/libGL.so.1.2.0
install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 ${D}${libdir}/libEGL.so.1.0.0
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
${D}${libdir}/libGLESv1_CM.so.1.1.0
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
${D}${libdir}/libGLESv2.so.2.0.0
ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2
# Install extra NVIDIA libglvnd libraries
install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so
# Install extra EGL NVIDIA libraries
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 ${D}${libdir}/
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/
# Install extra GL NVIDIA libraries
install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/
# Install libraries dependent on libglvnd libs
install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so
install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/
# nvcamera_daemon and argus_daemon have hard-coded path for this
install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
ln -sf ${libdir}/libEGL.so.1.0.0
${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so
}
PACKAGE_ARCH = "${MACHINE_ARCH}"
FILES_libgles1-tegra += "\
${libdir}/libGLESv1* \
"
FILES_libgles2-tegra += "\
${libdir}/libGLESv2* \
"
FILES_libegl-tegra += "\
${libdir}/libEGL* \
${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so \
"
FILES_libgl-tegra += "\
${libdir}/libGL.* \
${libdir}/libGLX* \
${libdir}/libGLdispatch.so* \
${libdir}/libnvidia-glsi.so.28.2.1 \
${libdir}/libnvbuf_utils.so* \
${libdir}/libnvddk_vic.so \
${libdir}/libnvddk_2d_v2.so \
"
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"
PRIVATE_LIBS = "libGL.so.1 libEGL.so.1 libGLESv2.so.2 libGLESv1_CM.so.1"
On Tue, Mar 5, 2019 at 12:06 PM Burton, Ross <ross.burton@intel.com> wrote:
>
> 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@gmail.com> wrote:
> >
> > HI Ross
> > On Tue, Mar 5, 2019 at 11:58 AM Burton, Ross <ross.burton@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@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@lists.openembedded.org
> > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> >
> >
> > --
> > Ricardo Ribalda
--
Ricardo Ribalda
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Two recipes providing the same .so... How it should not be done :)
@ 2019-03-05 11:09 ` Ricardo Ribalda Delgado
0 siblings, 0 replies; 18+ messages in thread
From: Ricardo Ribalda Delgado @ 2019-03-05 11:09 UTC (permalink / raw)
To: Burton, Ross; +Cc: Daniel Gomez, bitbake-devel, openembedded-core
This is my approach (which is not more than a horrible hack)
DESCRIPTION = "Tegra replacements for mesa libraries"
require recipes-bsp/tegra-binaries/tegra-glvnd.inc
RDEPENDS_libgl-mesa = "tegra-lib-common libegl-mesa libxcb-glx
libxxf86vm libxdamage libxcb-xfixes"
RDEPENDS_libegl-mesa = "zlib libxcb-xfixes libxcb-present libdrm
libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
libx11 libx11-xcb"
RDEPENDS_libgles2-mesa = "libdrm libglapi"
RDEPENDS_libgles1-mesa = "libdrm libglapi"
RPROVIDES_libgl-mesa += "gl-proprietary libgl"
RPROVIDES_libegl-mesa += "libegl"
RPROVIDES_libgles2-mesa += "libgles2"
RPROVIDES_libgles1-mesa += "libgles1"
PV = "${L4T_RELEASE}"
PE = "5"
PACKAGES = "libgl-mesa libegl-mesa libgles2-mesa libgles1-mesa"
L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"
do_unpack_append() {
bb.build.exec_func("unpack_l4t_tar", d)
}
unpack_l4t_tar() {
install -d ${L4T_GLVND_DIR}
tar -C ${L4T_GLVND_DIR} -x -f \
${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
usr/lib/aarch64-linux-gnu/tegra \
usr/lib/aarch64-linux-gnu/tegra-egl
}
do_compile[noexec] = "1"
PACKAGEFUNCS_append = " rm_pkgdata_runtime"
rm_pkgdata_runtime() {
rm -rf ${WORKDIR}/pkgdata/runtime/*
rm -rf ${WORKDIR}/pkgdata/shlibs2/*
}
do_install() {
install -d ${D}${libdir}
# Install NVIDIA mesa libraries (libglvnd)
install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 ${D}${libdir}/libGL.so.1.2.0
install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 ${D}${libdir}/libEGL.so.1.0.0
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
${D}${libdir}/libGLESv1_CM.so.1.1.0
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
${D}${libdir}/libGLESv2.so.2.0.0
ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2
# Install extra NVIDIA libglvnd libraries
install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so
# Install extra EGL NVIDIA libraries
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 ${D}${libdir}/
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/
# Install extra GL NVIDIA libraries
install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/
# Install libraries dependent on libglvnd libs
install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so
install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/
# nvcamera_daemon and argus_daemon have hard-coded path for this
install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
ln -sf ${libdir}/libEGL.so.1.0.0
${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so
}
PACKAGE_ARCH = "${MACHINE_ARCH}"
FILES_libgles1-mesa += "\
${libdir}/libGLESv1* \
"
FILES_libgles2-mesa += "\
${libdir}/libGLESv2* \
"
FILES_libegl-mesa += "\
${libdir}/libEGL* \
${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so \
"
FILES_libgl-mesa += "\
${libdir}/libGL.* \
${libdir}/libGLX* \
${libdir}/libGLdispatch.so* \
${libdir}/libnvidia-glsi.so.28.2.1 \
${libdir}/libnvbuf_utils.so* \
${libdir}/libnvddk_vic.so \
${libdir}/libnvddk_2d_v2.so \
"
INSANE_SKIP_${PN} = "already-stripped"
INSANE_SKIP_libegl-mesa = "ldflags dev-so"
INSANE_SKIP_libgles1-mesa = "ldflags dev-so"
INSANE_SKIP_libgles2-mesa = "ldflags"
INSANE_SKIP_libgl-mesa = "ldflags dev-so textrel"
PRIVATE_LIBS = "libGL.so.1 libEGL.so.1 libGLESv2.so.2 libGLESv1_CM.so.1"
read_subpackage_metadata () {
}
This is as Richard suggested:
DESCRIPTION = "Tegra replacements for mesa libraries"
require recipes-bsp/tegra-binaries/tegra-glvnd.inc
RDEPENDS_libgl-tegra = "tegra-lib-common libegl-tegra libxcb-glx
libxxf86vm libxdamage libxcb-xfixes"
RDEPENDS_libegl-tegra = "zlib libxcb-xfixes libxcb-present libdrm
libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
libx11 libx11-xcb"
RDEPENDS_libgles2-tegra = "libdrm libglapi"
RDEPENDS_libgles1-tegra = "libdrm libglapi"
PV = "${L4T_RELEASE}"
PE = "5"
PACKAGES = "libgl-tegra libegl-tegra libgles2-tegra libgles1-tegra"
L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"
do_unpack_append() {
bb.build.exec_func("unpack_l4t_tar", d)
}
unpack_l4t_tar() {
install -d ${L4T_GLVND_DIR}
tar -C ${L4T_GLVND_DIR} -x -f \
${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
usr/lib/aarch64-linux-gnu/tegra \
usr/lib/aarch64-linux-gnu/tegra-egl
}
do_compile[noexec] = "1"
do_install() {
install -d ${D}${libdir}
# Install NVIDIA mesa libraries (libglvnd)
install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 ${D}${libdir}/libGL.so.1.2.0
install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 ${D}${libdir}/libEGL.so.1.0.0
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
${D}${libdir}/libGLESv1_CM.so.1.1.0
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
${D}${libdir}/libGLESv2.so.2.0.0
ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2
# Install extra NVIDIA libglvnd libraries
install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so
# Install extra EGL NVIDIA libraries
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 ${D}${libdir}/
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/
# Install extra GL NVIDIA libraries
install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/
# Install libraries dependent on libglvnd libs
install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so
install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/
# nvcamera_daemon and argus_daemon have hard-coded path for this
install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
ln -sf ${libdir}/libEGL.so.1.0.0
${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so
}
PACKAGE_ARCH = "${MACHINE_ARCH}"
FILES_libgles1-tegra += "\
${libdir}/libGLESv1* \
"
FILES_libgles2-tegra += "\
${libdir}/libGLESv2* \
"
FILES_libegl-tegra += "\
${libdir}/libEGL* \
${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so \
"
FILES_libgl-tegra += "\
${libdir}/libGL.* \
${libdir}/libGLX* \
${libdir}/libGLdispatch.so* \
${libdir}/libnvidia-glsi.so.28.2.1 \
${libdir}/libnvbuf_utils.so* \
${libdir}/libnvddk_vic.so \
${libdir}/libnvddk_2d_v2.so \
"
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"
PRIVATE_LIBS = "libGL.so.1 libEGL.so.1 libGLESv2.so.2 libGLESv1_CM.so.1"
On Tue, Mar 5, 2019 at 12:06 PM Burton, Ross <ross.burton@intel.com> wrote:
>
> 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@gmail.com> wrote:
> >
> > HI Ross
> > On Tue, Mar 5, 2019 at 11:58 AM Burton, Ross <ross.burton@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@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@lists.openembedded.org
> > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> >
> >
> > --
> > Ricardo Ribalda
--
Ricardo Ribalda
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core] Two recipes providing the same .so... How it should not be done :)
2019-03-05 11:09 ` Ricardo Ribalda Delgado
@ 2019-03-05 11:17 ` Burton, Ross
-1 siblings, 0 replies; 18+ messages in thread
From: Burton, Ross @ 2019-03-05 11:17 UTC (permalink / raw)
To: Ricardo Ribalda Delgado; +Cc: Daniel Gomez, bitbake-devel, openembedded-core
Isn't this something that https://github.com/madisongh/meta-tegra already does?
Ross
On Tue, 5 Mar 2019 at 11:10, Ricardo Ribalda Delgado
<ricardo.ribalda@gmail.com> wrote:
>
> This is my approach (which is not more than a horrible hack)
>
> DESCRIPTION = "Tegra replacements for mesa libraries"
> require recipes-bsp/tegra-binaries/tegra-glvnd.inc
> RDEPENDS_libgl-mesa = "tegra-lib-common libegl-mesa libxcb-glx
> libxxf86vm libxdamage libxcb-xfixes"
> RDEPENDS_libegl-mesa = "zlib libxcb-xfixes libxcb-present libdrm
> libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
> libx11 libx11-xcb"
> RDEPENDS_libgles2-mesa = "libdrm libglapi"
> RDEPENDS_libgles1-mesa = "libdrm libglapi"
> RPROVIDES_libgl-mesa += "gl-proprietary libgl"
> RPROVIDES_libegl-mesa += "libegl"
> RPROVIDES_libgles2-mesa += "libgles2"
> RPROVIDES_libgles1-mesa += "libgles1"
> PV = "${L4T_RELEASE}"
> PE = "5"
> PACKAGES = "libgl-mesa libegl-mesa libgles2-mesa libgles1-mesa"
> L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
> L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
> L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"
> do_unpack_append() {
> bb.build.exec_func("unpack_l4t_tar", d)
> }
> unpack_l4t_tar() {
> install -d ${L4T_GLVND_DIR}
> tar -C ${L4T_GLVND_DIR} -x -f \
> ${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
> usr/lib/aarch64-linux-gnu/tegra \
> usr/lib/aarch64-linux-gnu/tegra-egl
> }
> do_compile[noexec] = "1"
> PACKAGEFUNCS_append = " rm_pkgdata_runtime"
> rm_pkgdata_runtime() {
> rm -rf ${WORKDIR}/pkgdata/runtime/*
> rm -rf ${WORKDIR}/pkgdata/shlibs2/*
> }
> do_install() {
> install -d ${D}${libdir}
> # Install NVIDIA mesa libraries (libglvnd)
> install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 ${D}${libdir}/libGL.so.1.2.0
> install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 ${D}${libdir}/libEGL.so.1.0.0
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
> ${D}${libdir}/libGLESv1_CM.so.1.1.0
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
> ${D}${libdir}/libGLESv2.so.2.0.0
> ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
> ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
> ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
> ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
> ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2
> # Install extra NVIDIA libglvnd libraries
> install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
> install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
> ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
> ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so
> # Install extra EGL NVIDIA libraries
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 ${D}${libdir}/
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/
> # Install extra GL NVIDIA libraries
> install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/
> # Install libraries dependent on libglvnd libs
> install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/
> install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 ${D}${libdir}/
> install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
> ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
> ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so
> install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
> install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/
> # nvcamera_daemon and argus_daemon have hard-coded path for this
> install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
> ln -sf ${libdir}/libEGL.so.1.0.0
> ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so
> }
> PACKAGE_ARCH = "${MACHINE_ARCH}"
> FILES_libgles1-mesa += "\
> ${libdir}/libGLESv1* \
> "
> FILES_libgles2-mesa += "\
> ${libdir}/libGLESv2* \
> "
> FILES_libegl-mesa += "\
> ${libdir}/libEGL* \
> ${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so \
> "
> FILES_libgl-mesa += "\
> ${libdir}/libGL.* \
> ${libdir}/libGLX* \
> ${libdir}/libGLdispatch.so* \
> ${libdir}/libnvidia-glsi.so.28.2.1 \
> ${libdir}/libnvbuf_utils.so* \
> ${libdir}/libnvddk_vic.so \
> ${libdir}/libnvddk_2d_v2.so \
> "
> INSANE_SKIP_${PN} = "already-stripped"
> INSANE_SKIP_libegl-mesa = "ldflags dev-so"
> INSANE_SKIP_libgles1-mesa = "ldflags dev-so"
> INSANE_SKIP_libgles2-mesa = "ldflags"
> INSANE_SKIP_libgl-mesa = "ldflags dev-so textrel"
> PRIVATE_LIBS = "libGL.so.1 libEGL.so.1 libGLESv2.so.2 libGLESv1_CM.so.1"
> read_subpackage_metadata () {
> }
>
>
> This is as Richard suggested:
>
> DESCRIPTION = "Tegra replacements for mesa libraries"
>
> require recipes-bsp/tegra-binaries/tegra-glvnd.inc
>
> RDEPENDS_libgl-tegra = "tegra-lib-common libegl-tegra libxcb-glx
> libxxf86vm libxdamage libxcb-xfixes"
> RDEPENDS_libegl-tegra = "zlib libxcb-xfixes libxcb-present libdrm
> libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
> libx11 libx11-xcb"
> RDEPENDS_libgles2-tegra = "libdrm libglapi"
> RDEPENDS_libgles1-tegra = "libdrm libglapi"
>
> PV = "${L4T_RELEASE}"
> PE = "5"
>
> PACKAGES = "libgl-tegra libegl-tegra libgles2-tegra libgles1-tegra"
>
> L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
> L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
> L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"
>
> do_unpack_append() {
> bb.build.exec_func("unpack_l4t_tar", d)
> }
>
> unpack_l4t_tar() {
> install -d ${L4T_GLVND_DIR}
> tar -C ${L4T_GLVND_DIR} -x -f \
> ${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
> usr/lib/aarch64-linux-gnu/tegra \
> usr/lib/aarch64-linux-gnu/tegra-egl
> }
>
> do_compile[noexec] = "1"
>
> do_install() {
> install -d ${D}${libdir}
> # Install NVIDIA mesa libraries (libglvnd)
> install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 ${D}${libdir}/libGL.so.1.2.0
> install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 ${D}${libdir}/libEGL.so.1.0.0
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
> ${D}${libdir}/libGLESv1_CM.so.1.1.0
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
> ${D}${libdir}/libGLESv2.so.2.0.0
> ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
> ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
> ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
> ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
> ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2
>
> # Install extra NVIDIA libglvnd libraries
> install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
> install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
> ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
> ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so
>
> # Install extra EGL NVIDIA libraries
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 ${D}${libdir}/
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/
>
> # Install extra GL NVIDIA libraries
> install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/
>
> # Install libraries dependent on libglvnd libs
> install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/
>
> install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 ${D}${libdir}/
>
> install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
> ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
> ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so
>
> install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
> install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/
>
> # nvcamera_daemon and argus_daemon have hard-coded path for this
> install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
> ln -sf ${libdir}/libEGL.so.1.0.0
> ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so
> }
>
> PACKAGE_ARCH = "${MACHINE_ARCH}"
>
> FILES_libgles1-tegra += "\
> ${libdir}/libGLESv1* \
> "
>
> FILES_libgles2-tegra += "\
> ${libdir}/libGLESv2* \
> "
>
> FILES_libegl-tegra += "\
> ${libdir}/libEGL* \
> ${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so \
> "
>
> FILES_libgl-tegra += "\
> ${libdir}/libGL.* \
> ${libdir}/libGLX* \
> ${libdir}/libGLdispatch.so* \
> ${libdir}/libnvidia-glsi.so.28.2.1 \
> ${libdir}/libnvbuf_utils.so* \
> ${libdir}/libnvddk_vic.so \
> ${libdir}/libnvddk_2d_v2.so \
> "
>
> 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"
>
>
> PRIVATE_LIBS = "libGL.so.1 libEGL.so.1 libGLESv2.so.2 libGLESv1_CM.so.1"
>
> On Tue, Mar 5, 2019 at 12:06 PM Burton, Ross <ross.burton@intel.com> wrote:
> >
> > 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@gmail.com> wrote:
> > >
> > > HI Ross
> > > On Tue, Mar 5, 2019 at 11:58 AM Burton, Ross <ross.burton@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@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@lists.openembedded.org
> > > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > >
> > >
> > >
> > > --
> > > Ricardo Ribalda
>
>
>
> --
> Ricardo Ribalda
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Two recipes providing the same .so... How it should not be done :)
@ 2019-03-05 11:17 ` Burton, Ross
0 siblings, 0 replies; 18+ messages in thread
From: Burton, Ross @ 2019-03-05 11:17 UTC (permalink / raw)
To: Ricardo Ribalda Delgado; +Cc: Daniel Gomez, bitbake-devel, openembedded-core
Isn't this something that https://github.com/madisongh/meta-tegra already does?
Ross
On Tue, 5 Mar 2019 at 11:10, Ricardo Ribalda Delgado
<ricardo.ribalda@gmail.com> wrote:
>
> This is my approach (which is not more than a horrible hack)
>
> DESCRIPTION = "Tegra replacements for mesa libraries"
> require recipes-bsp/tegra-binaries/tegra-glvnd.inc
> RDEPENDS_libgl-mesa = "tegra-lib-common libegl-mesa libxcb-glx
> libxxf86vm libxdamage libxcb-xfixes"
> RDEPENDS_libegl-mesa = "zlib libxcb-xfixes libxcb-present libdrm
> libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
> libx11 libx11-xcb"
> RDEPENDS_libgles2-mesa = "libdrm libglapi"
> RDEPENDS_libgles1-mesa = "libdrm libglapi"
> RPROVIDES_libgl-mesa += "gl-proprietary libgl"
> RPROVIDES_libegl-mesa += "libegl"
> RPROVIDES_libgles2-mesa += "libgles2"
> RPROVIDES_libgles1-mesa += "libgles1"
> PV = "${L4T_RELEASE}"
> PE = "5"
> PACKAGES = "libgl-mesa libegl-mesa libgles2-mesa libgles1-mesa"
> L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
> L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
> L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"
> do_unpack_append() {
> bb.build.exec_func("unpack_l4t_tar", d)
> }
> unpack_l4t_tar() {
> install -d ${L4T_GLVND_DIR}
> tar -C ${L4T_GLVND_DIR} -x -f \
> ${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
> usr/lib/aarch64-linux-gnu/tegra \
> usr/lib/aarch64-linux-gnu/tegra-egl
> }
> do_compile[noexec] = "1"
> PACKAGEFUNCS_append = " rm_pkgdata_runtime"
> rm_pkgdata_runtime() {
> rm -rf ${WORKDIR}/pkgdata/runtime/*
> rm -rf ${WORKDIR}/pkgdata/shlibs2/*
> }
> do_install() {
> install -d ${D}${libdir}
> # Install NVIDIA mesa libraries (libglvnd)
> install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 ${D}${libdir}/libGL.so.1.2.0
> install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 ${D}${libdir}/libEGL.so.1.0.0
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
> ${D}${libdir}/libGLESv1_CM.so.1.1.0
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
> ${D}${libdir}/libGLESv2.so.2.0.0
> ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
> ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
> ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
> ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
> ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2
> # Install extra NVIDIA libglvnd libraries
> install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
> install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
> ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
> ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so
> # Install extra EGL NVIDIA libraries
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 ${D}${libdir}/
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/
> # Install extra GL NVIDIA libraries
> install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/
> # Install libraries dependent on libglvnd libs
> install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/
> install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 ${D}${libdir}/
> install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
> ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
> ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so
> install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
> install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/
> # nvcamera_daemon and argus_daemon have hard-coded path for this
> install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
> ln -sf ${libdir}/libEGL.so.1.0.0
> ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so
> }
> PACKAGE_ARCH = "${MACHINE_ARCH}"
> FILES_libgles1-mesa += "\
> ${libdir}/libGLESv1* \
> "
> FILES_libgles2-mesa += "\
> ${libdir}/libGLESv2* \
> "
> FILES_libegl-mesa += "\
> ${libdir}/libEGL* \
> ${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so \
> "
> FILES_libgl-mesa += "\
> ${libdir}/libGL.* \
> ${libdir}/libGLX* \
> ${libdir}/libGLdispatch.so* \
> ${libdir}/libnvidia-glsi.so.28.2.1 \
> ${libdir}/libnvbuf_utils.so* \
> ${libdir}/libnvddk_vic.so \
> ${libdir}/libnvddk_2d_v2.so \
> "
> INSANE_SKIP_${PN} = "already-stripped"
> INSANE_SKIP_libegl-mesa = "ldflags dev-so"
> INSANE_SKIP_libgles1-mesa = "ldflags dev-so"
> INSANE_SKIP_libgles2-mesa = "ldflags"
> INSANE_SKIP_libgl-mesa = "ldflags dev-so textrel"
> PRIVATE_LIBS = "libGL.so.1 libEGL.so.1 libGLESv2.so.2 libGLESv1_CM.so.1"
> read_subpackage_metadata () {
> }
>
>
> This is as Richard suggested:
>
> DESCRIPTION = "Tegra replacements for mesa libraries"
>
> require recipes-bsp/tegra-binaries/tegra-glvnd.inc
>
> RDEPENDS_libgl-tegra = "tegra-lib-common libegl-tegra libxcb-glx
> libxxf86vm libxdamage libxcb-xfixes"
> RDEPENDS_libegl-tegra = "zlib libxcb-xfixes libxcb-present libdrm
> libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
> libx11 libx11-xcb"
> RDEPENDS_libgles2-tegra = "libdrm libglapi"
> RDEPENDS_libgles1-tegra = "libdrm libglapi"
>
> PV = "${L4T_RELEASE}"
> PE = "5"
>
> PACKAGES = "libgl-tegra libegl-tegra libgles2-tegra libgles1-tegra"
>
> L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
> L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
> L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"
>
> do_unpack_append() {
> bb.build.exec_func("unpack_l4t_tar", d)
> }
>
> unpack_l4t_tar() {
> install -d ${L4T_GLVND_DIR}
> tar -C ${L4T_GLVND_DIR} -x -f \
> ${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
> usr/lib/aarch64-linux-gnu/tegra \
> usr/lib/aarch64-linux-gnu/tegra-egl
> }
>
> do_compile[noexec] = "1"
>
> do_install() {
> install -d ${D}${libdir}
> # Install NVIDIA mesa libraries (libglvnd)
> install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 ${D}${libdir}/libGL.so.1.2.0
> install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 ${D}${libdir}/libEGL.so.1.0.0
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
> ${D}${libdir}/libGLESv1_CM.so.1.1.0
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
> ${D}${libdir}/libGLESv2.so.2.0.0
> ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
> ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
> ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
> ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
> ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2
>
> # Install extra NVIDIA libglvnd libraries
> install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
> install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
> ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
> ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so
>
> # Install extra EGL NVIDIA libraries
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 ${D}${libdir}/
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
> install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/
>
> # Install extra GL NVIDIA libraries
> install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/
>
> # Install libraries dependent on libglvnd libs
> install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/
>
> install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 ${D}${libdir}/
>
> install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
> ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
> ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so
>
> install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
> install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/
>
> # nvcamera_daemon and argus_daemon have hard-coded path for this
> install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
> ln -sf ${libdir}/libEGL.so.1.0.0
> ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so
> }
>
> PACKAGE_ARCH = "${MACHINE_ARCH}"
>
> FILES_libgles1-tegra += "\
> ${libdir}/libGLESv1* \
> "
>
> FILES_libgles2-tegra += "\
> ${libdir}/libGLESv2* \
> "
>
> FILES_libegl-tegra += "\
> ${libdir}/libEGL* \
> ${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so \
> "
>
> FILES_libgl-tegra += "\
> ${libdir}/libGL.* \
> ${libdir}/libGLX* \
> ${libdir}/libGLdispatch.so* \
> ${libdir}/libnvidia-glsi.so.28.2.1 \
> ${libdir}/libnvbuf_utils.so* \
> ${libdir}/libnvddk_vic.so \
> ${libdir}/libnvddk_2d_v2.so \
> "
>
> 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"
>
>
> PRIVATE_LIBS = "libGL.so.1 libEGL.so.1 libGLESv2.so.2 libGLESv1_CM.so.1"
>
> On Tue, Mar 5, 2019 at 12:06 PM Burton, Ross <ross.burton@intel.com> wrote:
> >
> > 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@gmail.com> wrote:
> > >
> > > HI Ross
> > > On Tue, Mar 5, 2019 at 11:58 AM Burton, Ross <ross.burton@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@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@lists.openembedded.org
> > > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > >
> > >
> > >
> > > --
> > > Ricardo Ribalda
>
>
>
> --
> Ricardo Ribalda
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core] Two recipes providing the same .so... How it should not be done :)
2019-03-05 11:17 ` Burton, Ross
@ 2019-03-05 11:20 ` Ricardo Ribalda Delgado
-1 siblings, 0 replies; 18+ messages in thread
From: Ricardo Ribalda Delgado @ 2019-03-05 11:20 UTC (permalink / raw)
To: Burton, Ross; +Cc: Daniel Gomez, bitbake-devel, openembedded-core
Yes, but I want to do it slightly differently
Instead of a big package with all the blobs I want to split it in
something that mimics the current package structure.
Also I want to run it inside a multiconfig setup.
Once everything works I want to upstream it to mesa-tegra.
On Tue, Mar 5, 2019 at 12:17 PM Burton, Ross <ross.burton@intel.com> wrote:
>
> Isn't this something that https://github.com/madisongh/meta-tegra already does?
>
> Ross
>
> On Tue, 5 Mar 2019 at 11:10, Ricardo Ribalda Delgado
> <ricardo.ribalda@gmail.com> wrote:
> >
> > This is my approach (which is not more than a horrible hack)
> >
> > DESCRIPTION = "Tegra replacements for mesa libraries"
> > require recipes-bsp/tegra-binaries/tegra-glvnd.inc
> > RDEPENDS_libgl-mesa = "tegra-lib-common libegl-mesa libxcb-glx
> > libxxf86vm libxdamage libxcb-xfixes"
> > RDEPENDS_libegl-mesa = "zlib libxcb-xfixes libxcb-present libdrm
> > libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
> > libx11 libx11-xcb"
> > RDEPENDS_libgles2-mesa = "libdrm libglapi"
> > RDEPENDS_libgles1-mesa = "libdrm libglapi"
> > RPROVIDES_libgl-mesa += "gl-proprietary libgl"
> > RPROVIDES_libegl-mesa += "libegl"
> > RPROVIDES_libgles2-mesa += "libgles2"
> > RPROVIDES_libgles1-mesa += "libgles1"
> > PV = "${L4T_RELEASE}"
> > PE = "5"
> > PACKAGES = "libgl-mesa libegl-mesa libgles2-mesa libgles1-mesa"
> > L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
> > L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
> > L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"
> > do_unpack_append() {
> > bb.build.exec_func("unpack_l4t_tar", d)
> > }
> > unpack_l4t_tar() {
> > install -d ${L4T_GLVND_DIR}
> > tar -C ${L4T_GLVND_DIR} -x -f \
> > ${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
> > usr/lib/aarch64-linux-gnu/tegra \
> > usr/lib/aarch64-linux-gnu/tegra-egl
> > }
> > do_compile[noexec] = "1"
> > PACKAGEFUNCS_append = " rm_pkgdata_runtime"
> > rm_pkgdata_runtime() {
> > rm -rf ${WORKDIR}/pkgdata/runtime/*
> > rm -rf ${WORKDIR}/pkgdata/shlibs2/*
> > }
> > do_install() {
> > install -d ${D}${libdir}
> > # Install NVIDIA mesa libraries (libglvnd)
> > install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 ${D}${libdir}/libGL.so.1.2.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 ${D}${libdir}/libEGL.so.1.0.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
> > ${D}${libdir}/libGLESv1_CM.so.1.1.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
> > ${D}${libdir}/libGLESv2.so.2.0.0
> > ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
> > ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
> > ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
> > ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
> > ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2
> > # Install extra NVIDIA libglvnd libraries
> > install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
> > ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
> > ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so
> > # Install extra EGL NVIDIA libraries
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 ${D}${libdir}/
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/
> > # Install extra GL NVIDIA libraries
> > install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/
> > # Install libraries dependent on libglvnd libs
> > install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
> > ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
> > ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so
> > install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/
> > # nvcamera_daemon and argus_daemon have hard-coded path for this
> > install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
> > ln -sf ${libdir}/libEGL.so.1.0.0
> > ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so
> > }
> > PACKAGE_ARCH = "${MACHINE_ARCH}"
> > FILES_libgles1-mesa += "\
> > ${libdir}/libGLESv1* \
> > "
> > FILES_libgles2-mesa += "\
> > ${libdir}/libGLESv2* \
> > "
> > FILES_libegl-mesa += "\
> > ${libdir}/libEGL* \
> > ${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so \
> > "
> > FILES_libgl-mesa += "\
> > ${libdir}/libGL.* \
> > ${libdir}/libGLX* \
> > ${libdir}/libGLdispatch.so* \
> > ${libdir}/libnvidia-glsi.so.28.2.1 \
> > ${libdir}/libnvbuf_utils.so* \
> > ${libdir}/libnvddk_vic.so \
> > ${libdir}/libnvddk_2d_v2.so \
> > "
> > INSANE_SKIP_${PN} = "already-stripped"
> > INSANE_SKIP_libegl-mesa = "ldflags dev-so"
> > INSANE_SKIP_libgles1-mesa = "ldflags dev-so"
> > INSANE_SKIP_libgles2-mesa = "ldflags"
> > INSANE_SKIP_libgl-mesa = "ldflags dev-so textrel"
> > PRIVATE_LIBS = "libGL.so.1 libEGL.so.1 libGLESv2.so.2 libGLESv1_CM.so.1"
> > read_subpackage_metadata () {
> > }
> >
> >
> > This is as Richard suggested:
> >
> > DESCRIPTION = "Tegra replacements for mesa libraries"
> >
> > require recipes-bsp/tegra-binaries/tegra-glvnd.inc
> >
> > RDEPENDS_libgl-tegra = "tegra-lib-common libegl-tegra libxcb-glx
> > libxxf86vm libxdamage libxcb-xfixes"
> > RDEPENDS_libegl-tegra = "zlib libxcb-xfixes libxcb-present libdrm
> > libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
> > libx11 libx11-xcb"
> > RDEPENDS_libgles2-tegra = "libdrm libglapi"
> > RDEPENDS_libgles1-tegra = "libdrm libglapi"
> >
> > PV = "${L4T_RELEASE}"
> > PE = "5"
> >
> > PACKAGES = "libgl-tegra libegl-tegra libgles2-tegra libgles1-tegra"
> >
> > L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
> > L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
> > L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"
> >
> > do_unpack_append() {
> > bb.build.exec_func("unpack_l4t_tar", d)
> > }
> >
> > unpack_l4t_tar() {
> > install -d ${L4T_GLVND_DIR}
> > tar -C ${L4T_GLVND_DIR} -x -f \
> > ${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
> > usr/lib/aarch64-linux-gnu/tegra \
> > usr/lib/aarch64-linux-gnu/tegra-egl
> > }
> >
> > do_compile[noexec] = "1"
> >
> > do_install() {
> > install -d ${D}${libdir}
> > # Install NVIDIA mesa libraries (libglvnd)
> > install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 ${D}${libdir}/libGL.so.1.2.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 ${D}${libdir}/libEGL.so.1.0.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
> > ${D}${libdir}/libGLESv1_CM.so.1.1.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
> > ${D}${libdir}/libGLESv2.so.2.0.0
> > ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
> > ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
> > ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
> > ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
> > ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2
> >
> > # Install extra NVIDIA libglvnd libraries
> > install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
> > ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
> > ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so
> >
> > # Install extra EGL NVIDIA libraries
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 ${D}${libdir}/
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/
> >
> > # Install extra GL NVIDIA libraries
> > install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/
> >
> > # Install libraries dependent on libglvnd libs
> > install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/
> >
> > install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 ${D}${libdir}/
> >
> > install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
> > ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
> > ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so
> >
> > install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/
> >
> > # nvcamera_daemon and argus_daemon have hard-coded path for this
> > install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
> > ln -sf ${libdir}/libEGL.so.1.0.0
> > ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so
> > }
> >
> > PACKAGE_ARCH = "${MACHINE_ARCH}"
> >
> > FILES_libgles1-tegra += "\
> > ${libdir}/libGLESv1* \
> > "
> >
> > FILES_libgles2-tegra += "\
> > ${libdir}/libGLESv2* \
> > "
> >
> > FILES_libegl-tegra += "\
> > ${libdir}/libEGL* \
> > ${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so \
> > "
> >
> > FILES_libgl-tegra += "\
> > ${libdir}/libGL.* \
> > ${libdir}/libGLX* \
> > ${libdir}/libGLdispatch.so* \
> > ${libdir}/libnvidia-glsi.so.28.2.1 \
> > ${libdir}/libnvbuf_utils.so* \
> > ${libdir}/libnvddk_vic.so \
> > ${libdir}/libnvddk_2d_v2.so \
> > "
> >
> > 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"
> >
> >
> > PRIVATE_LIBS = "libGL.so.1 libEGL.so.1 libGLESv2.so.2 libGLESv1_CM.so.1"
> >
> > On Tue, Mar 5, 2019 at 12:06 PM Burton, Ross <ross.burton@intel.com> wrote:
> > >
> > > 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@gmail.com> wrote:
> > > >
> > > > HI Ross
> > > > On Tue, Mar 5, 2019 at 11:58 AM Burton, Ross <ross.burton@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@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@lists.openembedded.org
> > > > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > > >
> > > >
> > > >
> > > > --
> > > > Ricardo Ribalda
> >
> >
> >
> > --
> > Ricardo Ribalda
--
Ricardo Ribalda
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Two recipes providing the same .so... How it should not be done :)
@ 2019-03-05 11:20 ` Ricardo Ribalda Delgado
0 siblings, 0 replies; 18+ messages in thread
From: Ricardo Ribalda Delgado @ 2019-03-05 11:20 UTC (permalink / raw)
To: Burton, Ross; +Cc: Daniel Gomez, bitbake-devel, openembedded-core
Yes, but I want to do it slightly differently
Instead of a big package with all the blobs I want to split it in
something that mimics the current package structure.
Also I want to run it inside a multiconfig setup.
Once everything works I want to upstream it to mesa-tegra.
On Tue, Mar 5, 2019 at 12:17 PM Burton, Ross <ross.burton@intel.com> wrote:
>
> Isn't this something that https://github.com/madisongh/meta-tegra already does?
>
> Ross
>
> On Tue, 5 Mar 2019 at 11:10, Ricardo Ribalda Delgado
> <ricardo.ribalda@gmail.com> wrote:
> >
> > This is my approach (which is not more than a horrible hack)
> >
> > DESCRIPTION = "Tegra replacements for mesa libraries"
> > require recipes-bsp/tegra-binaries/tegra-glvnd.inc
> > RDEPENDS_libgl-mesa = "tegra-lib-common libegl-mesa libxcb-glx
> > libxxf86vm libxdamage libxcb-xfixes"
> > RDEPENDS_libegl-mesa = "zlib libxcb-xfixes libxcb-present libdrm
> > libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
> > libx11 libx11-xcb"
> > RDEPENDS_libgles2-mesa = "libdrm libglapi"
> > RDEPENDS_libgles1-mesa = "libdrm libglapi"
> > RPROVIDES_libgl-mesa += "gl-proprietary libgl"
> > RPROVIDES_libegl-mesa += "libegl"
> > RPROVIDES_libgles2-mesa += "libgles2"
> > RPROVIDES_libgles1-mesa += "libgles1"
> > PV = "${L4T_RELEASE}"
> > PE = "5"
> > PACKAGES = "libgl-mesa libegl-mesa libgles2-mesa libgles1-mesa"
> > L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
> > L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
> > L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"
> > do_unpack_append() {
> > bb.build.exec_func("unpack_l4t_tar", d)
> > }
> > unpack_l4t_tar() {
> > install -d ${L4T_GLVND_DIR}
> > tar -C ${L4T_GLVND_DIR} -x -f \
> > ${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
> > usr/lib/aarch64-linux-gnu/tegra \
> > usr/lib/aarch64-linux-gnu/tegra-egl
> > }
> > do_compile[noexec] = "1"
> > PACKAGEFUNCS_append = " rm_pkgdata_runtime"
> > rm_pkgdata_runtime() {
> > rm -rf ${WORKDIR}/pkgdata/runtime/*
> > rm -rf ${WORKDIR}/pkgdata/shlibs2/*
> > }
> > do_install() {
> > install -d ${D}${libdir}
> > # Install NVIDIA mesa libraries (libglvnd)
> > install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 ${D}${libdir}/libGL.so.1.2.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 ${D}${libdir}/libEGL.so.1.0.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
> > ${D}${libdir}/libGLESv1_CM.so.1.1.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
> > ${D}${libdir}/libGLESv2.so.2.0.0
> > ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
> > ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
> > ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
> > ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
> > ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2
> > # Install extra NVIDIA libglvnd libraries
> > install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
> > ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
> > ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so
> > # Install extra EGL NVIDIA libraries
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 ${D}${libdir}/
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/
> > # Install extra GL NVIDIA libraries
> > install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/
> > # Install libraries dependent on libglvnd libs
> > install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
> > ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
> > ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so
> > install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/
> > # nvcamera_daemon and argus_daemon have hard-coded path for this
> > install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
> > ln -sf ${libdir}/libEGL.so.1.0.0
> > ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so
> > }
> > PACKAGE_ARCH = "${MACHINE_ARCH}"
> > FILES_libgles1-mesa += "\
> > ${libdir}/libGLESv1* \
> > "
> > FILES_libgles2-mesa += "\
> > ${libdir}/libGLESv2* \
> > "
> > FILES_libegl-mesa += "\
> > ${libdir}/libEGL* \
> > ${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so \
> > "
> > FILES_libgl-mesa += "\
> > ${libdir}/libGL.* \
> > ${libdir}/libGLX* \
> > ${libdir}/libGLdispatch.so* \
> > ${libdir}/libnvidia-glsi.so.28.2.1 \
> > ${libdir}/libnvbuf_utils.so* \
> > ${libdir}/libnvddk_vic.so \
> > ${libdir}/libnvddk_2d_v2.so \
> > "
> > INSANE_SKIP_${PN} = "already-stripped"
> > INSANE_SKIP_libegl-mesa = "ldflags dev-so"
> > INSANE_SKIP_libgles1-mesa = "ldflags dev-so"
> > INSANE_SKIP_libgles2-mesa = "ldflags"
> > INSANE_SKIP_libgl-mesa = "ldflags dev-so textrel"
> > PRIVATE_LIBS = "libGL.so.1 libEGL.so.1 libGLESv2.so.2 libGLESv1_CM.so.1"
> > read_subpackage_metadata () {
> > }
> >
> >
> > This is as Richard suggested:
> >
> > DESCRIPTION = "Tegra replacements for mesa libraries"
> >
> > require recipes-bsp/tegra-binaries/tegra-glvnd.inc
> >
> > RDEPENDS_libgl-tegra = "tegra-lib-common libegl-tegra libxcb-glx
> > libxxf86vm libxdamage libxcb-xfixes"
> > RDEPENDS_libegl-tegra = "zlib libxcb-xfixes libxcb-present libdrm
> > libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
> > libx11 libx11-xcb"
> > RDEPENDS_libgles2-tegra = "libdrm libglapi"
> > RDEPENDS_libgles1-tegra = "libdrm libglapi"
> >
> > PV = "${L4T_RELEASE}"
> > PE = "5"
> >
> > PACKAGES = "libgl-tegra libegl-tegra libgles2-tegra libgles1-tegra"
> >
> > L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
> > L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
> > L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"
> >
> > do_unpack_append() {
> > bb.build.exec_func("unpack_l4t_tar", d)
> > }
> >
> > unpack_l4t_tar() {
> > install -d ${L4T_GLVND_DIR}
> > tar -C ${L4T_GLVND_DIR} -x -f \
> > ${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
> > usr/lib/aarch64-linux-gnu/tegra \
> > usr/lib/aarch64-linux-gnu/tegra-egl
> > }
> >
> > do_compile[noexec] = "1"
> >
> > do_install() {
> > install -d ${D}${libdir}
> > # Install NVIDIA mesa libraries (libglvnd)
> > install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 ${D}${libdir}/libGL.so.1.2.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 ${D}${libdir}/libEGL.so.1.0.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
> > ${D}${libdir}/libGLESv1_CM.so.1.1.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
> > ${D}${libdir}/libGLESv2.so.2.0.0
> > ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
> > ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
> > ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
> > ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
> > ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2
> >
> > # Install extra NVIDIA libglvnd libraries
> > install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
> > ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
> > ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so
> >
> > # Install extra EGL NVIDIA libraries
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 ${D}${libdir}/
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/
> >
> > # Install extra GL NVIDIA libraries
> > install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/
> >
> > # Install libraries dependent on libglvnd libs
> > install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/
> >
> > install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 ${D}${libdir}/
> >
> > install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
> > ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
> > ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so
> >
> > install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/
> >
> > # nvcamera_daemon and argus_daemon have hard-coded path for this
> > install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
> > ln -sf ${libdir}/libEGL.so.1.0.0
> > ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so
> > }
> >
> > PACKAGE_ARCH = "${MACHINE_ARCH}"
> >
> > FILES_libgles1-tegra += "\
> > ${libdir}/libGLESv1* \
> > "
> >
> > FILES_libgles2-tegra += "\
> > ${libdir}/libGLESv2* \
> > "
> >
> > FILES_libegl-tegra += "\
> > ${libdir}/libEGL* \
> > ${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so \
> > "
> >
> > FILES_libgl-tegra += "\
> > ${libdir}/libGL.* \
> > ${libdir}/libGLX* \
> > ${libdir}/libGLdispatch.so* \
> > ${libdir}/libnvidia-glsi.so.28.2.1 \
> > ${libdir}/libnvbuf_utils.so* \
> > ${libdir}/libnvddk_vic.so \
> > ${libdir}/libnvddk_2d_v2.so \
> > "
> >
> > 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"
> >
> >
> > PRIVATE_LIBS = "libGL.so.1 libEGL.so.1 libGLESv2.so.2 libGLESv1_CM.so.1"
> >
> > On Tue, Mar 5, 2019 at 12:06 PM Burton, Ross <ross.burton@intel.com> wrote:
> > >
> > > 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@gmail.com> wrote:
> > > >
> > > > HI Ross
> > > > On Tue, Mar 5, 2019 at 11:58 AM Burton, Ross <ross.burton@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@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@lists.openembedded.org
> > > > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > > >
> > > >
> > > >
> > > > --
> > > > Ricardo Ribalda
> >
> >
> >
> > --
> > Ricardo Ribalda
--
Ricardo Ribalda
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2019-03-05 11:21 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-01 11:28 Two recipes providing the same .so... How it should not be done :) Ricardo Ribalda Delgado
2019-03-02 12:21 ` [OE-core] " Richard Purdie
2019-03-02 12:21 ` Richard Purdie
2019-03-05 8:27 ` Ricardo Ribalda Delgado
2019-03-05 9:37 ` Richard Purdie
2019-03-05 10:51 ` Ricardo Ribalda Delgado
2019-03-05 10:58 ` [OE-core] " Burton, Ross
2019-03-05 10:58 ` Burton, Ross
2019-03-05 11:00 ` [OE-core] " Ricardo Ribalda Delgado
2019-03-05 11:00 ` Ricardo Ribalda Delgado
2019-03-05 11:06 ` [OE-core] " Burton, Ross
2019-03-05 11:06 ` Burton, Ross
2019-03-05 11:09 ` [OE-core] " Ricardo Ribalda Delgado
2019-03-05 11:09 ` Ricardo Ribalda Delgado
2019-03-05 11:17 ` [OE-core] " Burton, Ross
2019-03-05 11:17 ` Burton, Ross
2019-03-05 11:20 ` [OE-core] " Ricardo Ribalda Delgado
2019-03-05 11:20 ` Ricardo Ribalda Delgado
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.