> -----Original Message-----
> From: Mark Hatle <[email protected]>
> Sent: Thursday, November 27, 2025 16:52
> To: Marko, Peter (FT D EU SK BFS1) <[email protected]>; Steve
> Sakoman <[email protected]>; [email protected]
> Subject: Re: [OE-core][scarthgap 14/21] lib/oe/go: document map_arch, and 
> raise
> an error on unknown architecture
> 
> 
> 
> On 11/27/25 1:00 AM, Peter Marko via lists.openembedded.org wrote:
> >
> >
> >> -----Original Message-----
> >> From: [email protected] <openembedded-
> >> [email protected]> On Behalf Of Mark Hatle
> >> Sent: Thursday, November 27, 2025 2:02
> >> To: Steve Sakoman <[email protected]>; openembedded-
> >> [email protected]
> >> Subject: Re: [OE-core][scarthgap 14/21] lib/oe/go: document map_arch, and
> raise
> >> an error on unknown architecture
> >>
> >> I have a possible workaround, for microblaze, for this.
> >>
> >> Basically it's to force include a class that does:
> >>
> >> python __anonymous() {
> >>       if bb.data.inherits_class('goarch', d):
> >>           if d.getVar('TARGET_ARCH') in ['microblaze', 'microblazeel',
> >> 'microblazeeb']:
> >>               raise bb.parse.SkipRecipe("Go does not support microblaze.")
> >> }
> >>
> >> On 11/26/25 6:40 PM, Mark Hatle wrote:
> >>> This patch breaks Microblaze for me.
> >>>
> >>> Microblazeel is not in the list of course, but go doesn't support this
> architecture.
> >>>
> >>> During parsing of various things, instead of the component not being
> available I
> >>> now get many many lines similar to:
> >>>
> >>> WARNING: <recipe>: Exception during build_dependencies for GOARCH
> >>> WARNING: <recipe>: Error during finalize of <multiconfig>
> >>> ERROR: ExpansionError during parsing <recipe>
> >>> bb.data_smart.ExceptionError: Failure expanding TARGET_GOARCH,
> >> expression was
> >>> ${go_map_arch(d.getVar('TARGET_ARCH'), d)} which triggered exception
> >> KeyError:
> >>> 'Cannot map architecture microblazeel'
> >>> The variable dependency chain for the failure is: TARGET_GOARCH ->
> GOARCH
> >>>
> >>> (at which point parsing stops)
> >>>
> >>> I see no obvious way here to add an architecture that OE/Poky does not
> >> support,
> >>> which now makes this a hard error for any architecture not supported by 
> >>> the
> core
> >>> of OE and/or go.  (in the case of microblaze, rust and go are likely to 
> >>> never
> be
> >>> supported.  So there has to be a way for me to avoid the parse error in 
> >>> these
> >>> cases.)
> >
> > OK, that's unfortunate.
> >
> > However this is something that needed a review when pushed to master branch
> half a year ago.
> > This backport then just means you see it half a year ahead of migrating to 
> > new
> LTS release.
> >
> > Possibly submit a revert or other adaptation to master branch and we can
> backport it then to scarthgap .
> 
> I do NOT believe this should be reverted in master.  Master is different then
> scarthgap, and per my other reply to Peter Kjellerstedt I think it should be
> adjusted.  I'm willing to try to suggest the adjustments to master.
> 
> It's scarthgap that I think this should be reverted.  It's a change in 
> behavior
> from prior scarthgap and absolutely broke my existing (functional) layer.  
> With
> that said, I have a 'workaround' for it, but it's going to take me time to QA
> everything and get it in for my scarthgap users.
> 
> My objection is to changing system behavior in the LTS, nothing more in this
> case.

OK, no problem, I don’t insist on this commit to be present in scarthgap, I 
need the other ones from tat series for proper golang testing.
Feel free to send a revert commit.

Peter

> 
> --Mark
> 
> > Peter
> >
> >>>
> >>> On 11/22/25 4:14 PM, Steve Sakoman wrote:
> >>>> From: Ross Burton <[email protected]>
> >>>>
> >>>> Add a comment explaining what this function does and where the values
> >>>> come from.
> >>>>
> >>>> If the architecture isn't know, instead of returning an empty string
> >>>> which could fail mysteriously, raise a KeyError so it fails quickly.
> >>>>
> >>>> (From OE-Core rev: 025414c16319b068df1cd757ad9a3c987a6b871d)
> >>>>
> >>>> Signed-off-by: Ross Burton <[email protected]>
> >>>> Signed-off-by: Richard Purdie <[email protected]>
> >>>> Signed-off-by: Peter Marko <[email protected]>
> >>>> Signed-off-by: Steve Sakoman <[email protected]>
> >>>> ---
> >>>>     meta/lib/oe/go.py | 6 +++++-
> >>>>     1 file changed, 5 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/meta/lib/oe/go.py b/meta/lib/oe/go.py
> >>>> index dfd957d157..4559dc63b2 100644
> >>>> --- a/meta/lib/oe/go.py
> >>>> +++ b/meta/lib/oe/go.py
> >>>> @@ -7,6 +7,10 @@
> >>>>     import re
> >>>>
> >>>>     def map_arch(a):
> >>>> +    """
> >>>> +    Map our architecture names to Go's GOARCH names.
> >>>> +    See
> https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go
> >> for the complete list.
> >>>> +    """
> >>>>         if re.match('i.86', a):
> >>>>             return '386'
> >>>>         elif a == 'x86_64':
> >>>> @@ -31,4 +35,4 @@ def map_arch(a):
> >>>>             return 'riscv64'
> >>>>         elif a == 'loongarch64':
> >>>>             return 'loong64'
> >>>> -    return ''
> >>>> +    raise KeyError(f"Cannot map architecture {a}")
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> 
> >>>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#226846): 
https://lists.openembedded.org/g/openembedded-core/message/226846
Mute This Topic: https://lists.openembedded.org/mt/116430143/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to