On Fri, Jan 17, 2025 at 1:39 AM Richard Purdie via lists.openembedded.org
<[email protected]> wrote:
> 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 find it hard to get excited about supporting 32-bit in any current
platform. Yes, platforms like Beaglebone Black are 32-bit and still have
some life in them. But the only reason I enabled qemuarm in my WIP
meta-java continuous integration is legacy support. Old software needs to
migrate or be rewritten. We cannot forever stand still and continue to be
vulnerable to attacks that are hardly tested. A model where software is
written once and patched on life support for eternity is a fool’s errand.
>
>
> > 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
I would MUCH rather have a sane switch to enable clang at the cost of
abandoning 32-bit support. I have no customers requiring 32-bit support for
new products, only legacy. One customer does ship a BBB product, but that
is being phased out in favor of a beer, more capable 64-bit arm platform.
Any other 32-bit needs are purely proprietary third-party closed source
licensed software that increasingly looks like a waste of money. The modest
to poor support is not worth that cost. And who pays the exorbitant legal
fees for the lawsuits?
Let’s leave 32-bit to Zephyr and move on.
>
> Cheers,
>
> Richard
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2095):
https://lists.openembedded.org/g/openembedded-architecture/message/2095
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]]
-=-=-=-=-=-=-=-=-=-=-=-
