On Thu, 2024-09-19 at 05:48 -0700, Sadineni, Harish via lists.openembedded.org wrote: > From: Harish Sadineni <[email protected]> > > Fixes the follwing error while building nativesdk-binutils with i686-mingw32 > as SDKMACHINE: > ERROR: nativesdk-binutils-2.43.1-r0 do_package: QA Issue: nativesdk-binutils: > Files/directories > were installed but not shipped in any package: > > /usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-w64-mingw32/usr/lib/bfd-plugins > > /usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-w64-mingw32/usr/lib/bfd-plugins/libdep.dll > > Signed-off-by: Harish Sadineni <[email protected]> > --- > meta/recipes-devtools/binutils/binutils_2.43.1.bb | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/meta/recipes-devtools/binutils/binutils_2.43.1.bb > b/meta/recipes-devtools/binutils/binutils_2.43.1.bb > index 2cce40f1ef..eb7c16cbc4 100644 > --- a/meta/recipes-devtools/binutils/binutils_2.43.1.bb > +++ b/meta/recipes-devtools/binutils/binutils_2.43.1.bb > @@ -72,5 +72,6 @@ SRC_URI:append:class-nativesdk = " > file://0003-binutils-nativesdk-Search-for-al > > USE_ALTERNATIVES_FOR:class-nativesdk = "" > FILES:${PN}:append:class-nativesdk = " ${bindir}" > +FILES:${PN}:append:class-nativesdk = " ${libdir}/bfd-plugins" > > BBCLASSEXTEND = "native nativesdk"
I ended up digging into this a lot more. I was able to reproduce the failure locally but that implies the autobuilder isn't testing this combination. According to the configuration, it should be so I'm a bit puzzled why the autobuilder doesn't see it. The autobuilder config for this is here: https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json#n1362 Resulting in a build such as this: https://valkyrie.yoctoproject.org/#/builders/7/builds/162 I would like to understand why automated testing isn't catching this. Getting back to the patch, I noticed that bintutils.inc already does: FILES:${PN} = " \ ${bindir}/${TARGET_PREFIX}* \ ${libdir}/lib*.so.* \ ${libdir}/bfd-plugins/lib*.so \ ... and the issue is that it uses .so and the recipe is generating a .dll file. I'd note that bitbake.conf has: SOLIBS = ".so.*" SOLIBS:darwin = ".dylib" SOLIBSDEV = ".so" # Due to the ordering of PACKAGES and the naming of the dev symlinks on darwin, # we can't make the symlinks end up in the -dev packages easily at this point. This hack # at least means builds aren't completely broken and symlinks don't take up much space. SOLIBSDEV:darwin = ".dylibbroken" with the intent of being able to abstract out dylib/so/dll references. I'm wondering if we should add: SOLIBS:mingw32 = ".dll" SOLIBSDEV:mingw32 = ".dll" which would then let us change the binutils.inc entry to: ${libdir}/bfd-plugins/lib*${SOLIBSDEV} In testing this I found it breaks zstd and zlib since those always generate .so files even on mingw. I've hardcoded SOLIBS and SOLIBSDEV in the bbappends in mingw to counteract that: https://git.yoctoproject.org/meta-mingw/commit/?id=db1f53f73e95499a5f0b0edc45dd9cc9718d3c8a I think these changes should combine to fix the underlying problem and also make it easier to fix things like this in future. They probably need wider testing though. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204690): https://lists.openembedded.org/g/openembedded-core/message/204690 Mute This Topic: https://lists.openembedded.org/mt/108538762/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
