Re: [meta-arago][scarthgap/master][PATCH v2] ti-gc320-tests: Add RDEPENDS ti-gc320-libs-dev

[Randolph Sapp <rs@ti.com>]

On Thu Mar 6, 2025 at 6:31 PM CST, Denys Dmytriyenko wrote:
> On Thu, Mar 06, 2025 at 05:41:54PM -0600, Randolph Sapp wrote:
>> On Thu Mar 6, 2025 at 1:53 PM CST, Denys Dmytriyenko wrote:
>> > On Thu, Mar 06, 2025 at 12:50:56PM -0600, Antonios Christidis via lists.yoctoproject.org wrote:
>> >> 
>> >> On 3/6/25 11:35 AM, Andrew Davis wrote:
>> >> >On 3/6/25 11:29 AM, Antonios Christidis wrote:
>> >> >>
>> >> >>On 3/6/25 11:25 AM, Andrew Davis wrote:
>> >> >>>On 3/6/25 11:09 AM, Antonios Christidis wrote:
>> >> >>>>
>> >> >>>>On 3/6/25 10:57 AM, Andrew Davis wrote:
>> >> >>>>>On 3/6/25 10:03 AM, Antonios Christidis wrote:
>> >> >>>>>>
>> >> >>>>>>On 3/6/25 7:32 AM, Andrew Davis wrote:
>> >> >>>>>>>On 3/5/25 6:04 PM, a-christidis@ti.com wrote:
>> >> >>>>>>>>From: Antonios Christidis <a-christidis@ti.com>
>> >> >>>>>>>>
>> >> >>>>>>>>Include the package ti-gc320-libs-dev as a runtime dependency.
>> >> >>>>>>>>
>> >> >>>>>>>>Signed-off-by: Antonios Christidis <a-christidis@ti.com>
>> >> >>>>>>>>---
>> >> >>>>>>>>
>> >> >>>>>>>>v2:
>> >> >>>>>>>>- Added dev-deps on INSANE_SKIP
>> >> >>>>>>>>
>> >> >>>>>>>>  .../ti-gc320-tests/ti-gc320-tests_5.0.11.p7.bb | 3 ++-
>> >> >>>>>>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> >> >>>>>>>>
>> >> >>>>>>>>diff --git a/meta-arago-extras/recipes-graphics/ti-gc320-tests/ti-gc320-tests_5.0.11.p7.bb b/meta-arago-extras/recipes-graphics/ti-gc320-tests/ti-gc320-tests_5.0.11.p7.bb
>> >> >>>>>>>>
>> >> >>>>>>>>index f9b9685f..14278d76 100644
>> >> >>>>>>>>--- a/meta-arago-extras/recipes-graphics/ti-gc320-tests/ti-gc320-tests_5.0.11.p7.bb
>> >> >>>>>>>>+++ b/meta-arago-extras/recipes-graphics/ti-gc320-tests/ti-gc320-tests_5.0.11.p7.bb
>> >> >>>>>>>>@@ -4,6 +4,7 @@ LICENSE = "MIT"
>> >> >>>>>>>>  LIC_FILES_CHKSUM = "file://dra7x-sdk-ti-gc320-tests_manifest.html;md5=22a001855467f373c47f45de5330e3c9"
>> >> >>>>>>>>    DEPENDS = "ti-gc320-libs"
>> >> >>>>>>>>+RDEPENDS:${PN}:append = " ti-gc320-libs-dev"
>> >> >>>>>>>
>> >> >>>>>>>This should be detected and set for you based on DEPENDS. You don't
>> >> >>>>>>>need any change here.
>> >> >>>>>>>
>> >> >>>>>>>Andrew
>> >> >>>>>>>
>> >> >>>>>>The way DEPENDS is setup it will not include
>> >> >>>>>>ti-gc320-libs-dev package in the fs.
>> >> >>>>>>
>> >> >>>>>>  The contents of the -dev package are required at
>> >> >>>>>>runtime for the gc320 tests.
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>>Why? What is going into the dev package that is needed by the tests?
>> >> >>>>>
>> >> >>>>>Andrew
>> >> >>>>>
>> >> >>>>libGAL.so symb link.
>> >> >>>
>> >> >>>If users of this library are meant to dlopen() that file, then
>> >> >>>add it to the
>> >> >>>regular ti-gc320-libs package.
>> >> >>>
>> >> >>>
>> >> >>I did that in [1]. However, Denys let me know symb link should
>> >> >>go in the -dev package.
>> >> >>
>> >> >
>> >> >For header files I'd agree, and usually for .so files. But in this
>> >> >case if
>> >> >the users of this need this file (as in it is not just used for
>> >> >compiling)
>> >> >then it can go in the base package. We do this for instance with
>> >> >GStreamer
>> >> >plugins[0].
>> >> >
>> >> I prefer the above option. Ryan, Denys, Randolph what do you think ?
>> >
>> > 1. Is libGAL.so a symlink to a versioned libGAL.so.X.Y.Z or libGAL.so.X 
>> > library?
>> >
>> > 2. Does it get linked during compile time, like a regular shared library, 
>> > or is it meant to be dlopen()-ed?
>> >
>> >
>> > If it's a regular shared library and .so is a symlink to a versioned copy, 
>> > then .so should go into -dev package and you don't pull that package into 
>> > a rootfs, unless you want to enable on-target development.
>> >
>> > If it's a regular shared library that gets linked at build time, but there's 
>> > no versioned copies produced, as .so is the only output, then the best option 
>> > os to fix your build to produce versioned copies and .so synlink. Alternative, 
>> > but less desirable option, is to put .so library (not synlink) into the main 
>> > package, like Andrew mentioned.
>> >
>> > If this .so is meant to be dlopen() at runtime, then it should not be a 
>> > symlink, first of all, but then you also want to move it into the main 
>> > package.
>> 
>> Glad we all agree here. It's my understanding that multiple applications (both
>> in and out of our control) have gotten use to dlopen-ing that unversioned so.
>> It's a borderline requirement to have it now.
>> 
>> Antonios, the package should not produce any "-dev" package variant. Override
>> the PACKAGES, FILES, and INSANE_SKIP variables like mesa or the rogue-umlibs do
>> right now to do this correctly.
>
> Hold a sec, that was exactly the comment for the first revision of this 
> patch[1]. There's a default -dev package and it is correct, because besides 
> this .so there are also header files being installed, which do belong in the 
> corresponding -dev package. All that gets handled automatically. What we are 
> saying here is that if the unversioned .so needs to be dlopen()-ed, then it 
> can be moved to the main poackage.
>
> The proper way to do this:
> https://git.openembedded.org/openembedded-core/tree/meta/recipes-graphics/spir/spirv-tools_1.3.296.0.bb#n45
> https://git.yoctoproject.org/meta-arago/tree/meta-arago-extras/recipes-devtools/arm-compute-library/arm-compute-library_24.12.bb#n54
> https://git.yoctoproject.org/meta-arago/tree/meta-arago-extras/recipes-framework/onnx/onnx_1.16.1.bb#n103
>
>
> BTW, I don't see umlibs installing any header files, while mesa-pvr builds 
> on top of upstream mesa.inc, which packages different header files into 
> corresponding -dev packages...
>

That comment was specifically about the devlink issue. Mesa has a devlink for
GL/GLES/EGL implementations that hook back into the megadriver. These are in the
main megadriver package, not a dev package. The rogue-um recipe drops the dev
package entirely because various tools expect to interact with unversioned so's
for srv components and we don't have any headers to ship.

I was unaware there were also headers being included in this recipe. In that
case you are correct. The dev package must still be generated, the devlinks will
need to be cut out and included in the main package like mesa, though I admit
mesa is a more complex example of this.

>> > Also, you don't pull header files into the main package[1], even if you need 
>> > to enable on-target development - you use -dev package along with other 
>> > tools. Normally you enable that with "dev-pkgs" in IMAGE_FEATURES or globally 
>> > in EXTRA_IMAGE_FEATURES.
>> >
>> > And lastly - you don't ever want to try to pull even a single -dev package 
>> > explicitly via RDEPENDS, because it will trigger a chain reaction for many 
>> > other -dev packages, so it will blow up your dependency tree. I already 
>> > explained it here:
>> > https://lists.yoctoproject.org/g/meta-arago/message/15696
>> 
>> >> >Another option is to fix up the tests so they link with libGAL the
>> >> >normal way..
>> >> >
>> >> >[0] https://git.yoctoproject.org/meta-arago/tree/meta-arago-extras/recipes-multimedia/gst-plugins-ti/gstreamer1.0-plugins-hevc_git.bb?h=scarthgap#n32
>> >> >
>> >> >>[1] = https://patchwork.yoctoproject.org/project/ti/patch/20250212201830.2090247-3-a-christidis@ti.com/