On Wed, Oct 30, 2019 at 11:14:34AM -0400, Ruei, Eric wrote: > Hi, guys: > > Is there anything that we do regarding the large package size (1M to 8M)?
All the standard libs in /usr/lib get stripped properly. But there's a new /usr/lib/dri/pvr_dri.so that is 28 MB even stripped. Is it supposed to be this large? -- Denys > Best regards, > > Eric > > On 10/30/2019 11:06 AM, Denys Dmytriyenko wrote: > >On Wed, Oct 30, 2019 at 10:58:31AM -0400, Andrew F. Davis wrote: > >>On 10/30/19 10:53 AM, Ruei, Eric wrote: > >>>On 10/30/2019 9:53 AM, Tammana, Gowtham wrote: > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: [email protected] [mailto:meta-ti- > >>>>>[email protected]] On Behalf Of Davis, Andrew > >>>>>Sent: Wednesday, October 30, 2019 8:36 AM > >>>>>To: Ruei, Eric; Ruei, Eric; [email protected] > >>>>>Subject: [EXTERNAL] Re: [meta-ti] [PATCH] ti-sgx-ddk-um: update > >>>>>SRCREV to pick > >>>>>up Mesa-based EGL/GLES libraries > >>>>> > >>>>>On 10/30/19 9:31 AM, Ruei, Eric wrote: > >>>>>>On 10/30/2019 9:22 AM, Andrew F. Davis wrote: > >>>>>>>On 10/29/19 9:20 AM, Eric Ruei wrote: > >>>>>>>>This is the initial step toward Mesa-based EGL/GLES libraries which > >>>>>>>>support all the required EGL 1.5 extensions. We plan to provide a > >>>>>>>>Mesa-pvr recipe to build Mesa from source and SGX/DDK patches where > >>>>>>>>ti-sgx-ddk-um shall provide the EGL/GLES plugins only at the next > >>>>>>>>step. > >>>>>>>> > >>>>>>>>Signed-off-by: Eric Ruei <[email protected]> > >>>>>>>>--- > >>>>>>>> recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb | 8 > >>>>>>>>+++++--- > >>>>>>>> 1 file changed, 5 insertions(+), 3 deletions(-) > >>>>>>>> > >>>>>>>>diff --git a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb > >>>>>>>>b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb > >>>>>>>>index 7a6f013e..3991d917 100644 > >>>>>>>>--- a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb > >>>>>>>>+++ b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb > >>>>>>>>@@ -11,7 +11,7 @@ PR = "r34" > >>>>>>>> BRANCH = "ti-img-sgx/thud/${PV}" > >>>>>>>> SRC_URI = > >>>>>>>>"git://git.ti.com/graphics/omap5-sgx-ddk-um- > >>>>>linux.git;protocol=git;branch=${BRANCH}" > >>>>>>>> > >>>>>>>>-SRCREV = "87d7e5c1e4db1bab048939c9719059d549c1e8dd" > >>>>>>>>+SRCREV = "2a2e5bb090ced870d73ed4edbc54793e952cc6d8" > >>>>>>>> TARGET_PRODUCT_omap-a15 = "jacinto6evm" > >>>>>>>> TARGET_PRODUCT_ti33x = "ti335x" > >>>>>>>>@@ -47,7 +47,9 @@ S = "${WORKDIR}/git" > >>>>>>>> do_install () { > >>>>>>>> oe_runmake install DESTDIR=${D} > >>>>>>>>TARGET_PRODUCT=${TARGET_PRODUCT} > >>>>>>>>- ln -sf libGLESv2.so.${PV} ${D}${libdir}/libGLESv2.so.1 > >>>>>>>>+ ln -sf libGLESv2.so ${D}${libdir}/libGLESv2.so.1 > >>>>>>>>+ > >>>>>>>>+ rm -rf ${D}${includedir}/GL > >>>>>>> > >>>>>>> > >>>>>>>Why remove this? > >>>>>>> > >>>>>>> > >>>>>> > >>>>>>There is another component provides GL header files. > >>>>>>Denys: how do we resolve this conflict? > >>>>>> > >>>>> > >>>>> > >>>>>The DSP OpenCL implementation? That package needs fixed, not this one, > >>>>>the OpenGL implementation (this driver) should provide the GL headers. > >>>> > >>>>We don't support desktop GL, they shouldn't come from this package. > >>>> > >>>>Gowtham > >>>> > >>> > >>>Andrew: > >>> > >>>Do you agree? I can keep the line here tentatively until GL is removed > >>>from the package itself. > >>> > >> > >> > >>I still believe we should be shipping the GL headers in this package. > >>But I won't object to removing the headers temporarily using this recipe > >>until the conflicting ones can be removed from the OpenCL package. > > > >Previously DDK only provided headers in these dirs: EGL, GLES, GLES2, KHR, > >gbm. > > > >And OpenCL required GL headers, hence there was a "hacky" package created > >specifically for that: > >http://arago-project.org/git/?p=meta-arago.git;a=blob;f=meta-arago-extras/recipes-ti/ocl/ocl-gl-headers_git.bb;hb=HEAD > > > >If DDK now properly provides GL headers, the other package can be dropped. > > > >But the question remains - should DDK actually provide GL headers, even > >though > >it doesn't provide full support for it? > > > -- _______________________________________________ meta-ti mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-ti
