Hi Richard, Agree with you, the changing will break the stability of multilib bbclass extension, the existed multilib bbclass is complex enough.
But the root cause you figured out bright me the issue is that buildtools-extended-tarball doesn't contain 32 bit libgcc/glibc on 64 bit platforms and therefore can't build 32 bit binaries. If finding a way to provide the missing 32 bit libgcc/glibc for 64 bit platforms, the issue should be fixed. At first glance, I thought multiconfig. With a simple search, we could refer the multiconfig selftest case [1], add a nativesdk recipe nativesdk-multiconfig-multlib-toolchain-packager to fetch 32 bit libgcc/glibc from 32bit multiconfig build, package it and install to 64 bit buildtools-extended-tarball. Also reverse to fetch 64 bit libgcc/glibc from 64bit multiconfig build and instll to 32 bit buildtools-extended-tarball. Due to the supported SDKMACHINE includes: aarch64, i586, i686, loongarch64, ppc64, ppc64le, riscv64, x86_64 Only i586 and x86_64, i686 and x86_64 have multilib relationship, I will choose i686 and x86_64 as the example, mainly includes - Enhance GCC to enable multilib for i686/x86_64/i586 nativesdk gcc - Enhance SDK to support multilib dynamic loaders relocation - Add a nativesdk recipe inherit multiconfig bbclass to fetch and install missing libgcc/glibc - Add multiconfig configurations to build missing 32bit libgcc/glibc in x86 multiconfig build and install it to 64bit buildtools-extended-tarball in x86_64 multiconfig build, vice versa I think the multiconfig configuration should not be added as formal meta/conf, we could add it as a selftest case to show and verify the whole process I will send the patch for review later [1] https://github.com/openembedded/openembedded-core/blob/master/meta-selftest/recipes-test/multiconfig/multiconfig-image-packager_0.1.bb [https://opengraph.githubassets.com/7b1cdfae1615ec7e081a55b3f3df5ea3307c79065cdd6a4b7fc31fa6aa9e0438/openembedded/openembedded-core]<https://github.com/openembedded/openembedded-core/blob/master/meta-selftest/recipes-test/multiconfig/multiconfig-image-packager_0.1.bb> openembedded-core/meta-selftest/recipes-test/multiconfig/multiconfig-image-packager_0.1.bb at master ยท openembedded/openembedded-core - GitHub<https://github.com/openembedded/openembedded-core/blob/master/meta-selftest/recipes-test/multiconfig/multiconfig-image-packager_0.1.bb> You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. github.com //Hongxu ________________________________ From: Richard Purdie <[email protected]> Sent: Friday, January 17, 2025 5:38 PM To: Jia, Hongxu <[email protected]>; [email protected] <[email protected]> Cc: CDC-ENG-Linux-core-dev <[email protected]> Subject: Re: [Openembedded-architecture] [RFC] Enable multilib for nativesdk gcc CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe. On Fri, 2025-01-17 at 03:44 +0000, hongxu via lists.openembedded.org wrote: > The background is we used extended buildtools SDK to provide gcc and other > build tools on host for a Yocto build, but recipes that uses gcc-multilib > and glibc-multilib on host will fail with extended buildtools. For example, > lib32-luajit fails with extended buildtools. > > > With a simple search, we have enabled multilib for target gcc [1][2] > > > $ cat << ENDOF > main.c > #include <stdio.h> > int main() { > printf("Hello world"); > return 0; > } > ENDOF > > > $ gcc main.c -o main-64 > $ gcc -m32 main.c -o main-32 So to rephrase this, the issue is that buildtools-extended-tarball doesn't contain 32 bit libgcc/glibc on 64 bit platforms and therefore can't build 32 bit binaries. I guess the question is then, how often are people running into situations where they need to do this? > I am not sure it is worth to improve multilib bbclass to support nativesdk > extension, great efforts are needed and will make multilib bbclass more > complicated It would add a lot of complexity and the changes I'm proposing to the toolchain to make clang recipe selectable will probably conflict with it too. I'm not yet seeing a compelling case to add that complexity. We definitely could do it but I'm not convinced we should. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2094): https://lists.openembedded.org/g/openembedded-architecture/message/2094 Mute This Topic: https://lists.openembedded.org/mt/110660766/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
