| Message ID | 20250121085526.1370937-2-hongxu.jia@windriver.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/9] perl: fix do_install failed for nativesdk-perl | expand |
On Tue Jan 21, 2025 at 9:55 AM CET, hongxu via lists.openembedded.org wrote: > The nativesdk multilib support required it to fix multilib headers > conflict > > [ YOCTO #15722 ] > > Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> > --- Hi, I forgot to mention this last week, but it seems this patch is breaking builds with meta-mingw. https://autobuilder.yoctoproject.org/valkyrie/#/builders/7/builds/914/steps/12/logs/stdio Maybe this is something to fix in meta-mingw directly, but I'm not sure about what cause this issue.
On 21 Jan 2025, at 08:55, hongxu via lists.openembedded.org <hongxu.jia=eng.windriver.com@lists.openembedded.org> wrote: > The nativesdk multilib support required it to fix multilib headers > conflict So the context here is that luajit apparently needs to be able to build native code with the same word size as the target. But this demonstrates nicely that nobody has tried to build a 32-bit luajit on a 64-bit non-x86 machine, for example: | gcc: error: unrecognized command-line option ‘-m32’ So if the goal is “build luajit everywhere” then this doesn’t solve that problem. Ross
On Wed, 2025-01-29 at 16:58 +0000, Ross Burton via lists.openembedded.org wrote: > On 21 Jan 2025, at 08:55, hongxu via lists.openembedded.org > <hongxu.jia=eng.windriver.com@lists.openembedded.org> wrote: > > The nativesdk multilib support required it to fix multilib headers > > conflict > > So the context here is that luajit apparently needs to be able to > build native code with the same word size as the target. But this > demonstrates nicely that nobody has tried to build a 32-bit luajit on > a 64-bit non-x86 machine, for example: > > > gcc: error: unrecognized command-line option ‘-m32’ > > So if the goal is “build luajit everywhere” then this doesn’t solve > that problem. I've been giving this a lot of. Part of me does like this solution but equally, it is complicating something which is already quite complex for a comparatively isolated problem. As Ross mentions, it only fixes this for a small subsection there too, it isn't a universal fix. Some of the patches in the series are simple/trivial but others have what looks like quite fragile logic (e.g. the libgcc paths). I'm not convinced merging this and trying to support multilib nativesdk-gcc is in our best interests unfortunately. Cheers, Richard
Sorry for replying late, I am just back from the vacation On 2/6/25 15:39, Richard Purdie via lists.openembedded.org wrote: > 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 Wed, 2025-01-29 at 16:58 +0000, Ross Burton via > lists.openembedded.org wrote: >> On 21 Jan 2025, at 08:55, hongxu via lists.openembedded.org >> <hongxu.jia=eng.windriver.com@lists.openembedded.org> wrote: >>> The nativesdk multilib support required it to fix multilib headers >>> conflict >> So the context here is that luajit apparently needs to be able to >> build native code with the same word size as the target. But this >> demonstrates nicely that nobody has tried to build a 32-bit luajit on >> a 64-bit non-x86 machine, for example: >> >>> gcc: error: unrecognized command-line option ‘-m32’ >> So if the goal is “build luajit everywhere” then this doesn’t solve >> that problem. > I've been giving this a lot of. Part of me does like this solution but > equally, it is complicating something which is already quite complex > for a comparatively isolated problem. As Ross mentions, it only fixes > this for a small subsection there too, it isn't a universal fix. > > Some of the patches in the series are simple/trivial but others have > what looks like quite fragile logic (e.g. the libgcc paths). > > I'm not convinced merging this and trying to support multilib > nativesdk-gcc is in our best interests unfortunately. Agree with you, follow your suggestion, I will drop libgcc patches to supportmultilib nativesdk-gcc and pick up the simple/trivial patches from the series and resend them in v2, including: [OE-core] [PATCH 3/9] toolchain-shar-relocate.sh: support multiple dynamic loaders for multilib [OE-core] [PATCH 4/9] script/relocate_sdk.py: check dynamic loader arch before relocating interpreter //Hongxu > Cheers, > > Richard > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#210907):https://lists.openembedded.org/g/openembedded-core/message/210907 > Mute This Topic:https://lists.openembedded.org/mt/110730419/3617049 > Group Owner:openembedded-core+owner@lists.openembedded.org > Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [hongxu.jia@eng.windriver.com] > -=-=-=-=-=-=-=-=-=-=-=- >
diff --git a/meta/classes-recipe/multilib_header.bbclass b/meta/classes-recipe/multilib_header.bbclass index 33f7e027f0..b338166f61 100644 --- a/meta/classes-recipe/multilib_header.bbclass +++ b/meta/classes-recipe/multilib_header.bbclass @@ -51,8 +51,3 @@ oe_multilib_header() { oe_multilib_header:class-native () { return } - -# Nor do we need multilib headers for nativesdk builds. -oe_multilib_header:class-nativesdk () { - return -}
The nativesdk multilib support required it to fix multilib headers conflict [ YOCTO #15722 ] Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> --- meta/classes-recipe/multilib_header.bbclass | 5 ----- 1 file changed, 5 deletions(-)