Missing archs in build/gyp.mozbuild

RESOLVED FIXED in Firefox 30

Status

defect
RESOLVED FIXED
5 years ago
Last year

People

(Reporter: gaston, Assigned: glandium)

Tracking

Trunk
mozilla32
Sun
OpenBSD
Dependency tree / graph

Firefox Tracking Flags

(firefox30 fixed, firefox31 fixed, firefox32 fixed)

Details

(Whiteboard: [qa-])

Attachments

(3 attachments)

Reporter

Description

5 years ago
While trying the patches from 981780 on sparc64 (ie inconditionally build media/libyuv), i realized that build/gyp.mozbuild has yet another list of possible architectures, and it's lacking some (at least sparc*), which leads to this:

Traceback (most recent call last):
  File "./config.status", line 912, in <module>
    config_status(**args)
  File "/data/ports/firefox-30.0beta1/mozilla-beta/python/mozbuild/mozbuild/config_status.py", line 148, in config_status
    summary = the_backend.consume(definitions)
  File "/data/ports/firefox-30.0beta1/mozilla-beta/python/mozbuild/mozbuild/backend/base.py", line 186, in consume
    for obj in objs:
  File "/data/ports/firefox-30.0beta1/mozilla-beta/python/mozbuild/mozbuild/frontend/emitter.py", line 99, in emit
    for out in output:
  File "/data/ports/firefox-30.0beta1/mozilla-beta/python/mozbuild/mozbuild/frontend/reader.py", line 726, in read_mozbuild
    raise bre
mozbuild.frontend.reader.BuildReaderError: ==============================
ERROR PROCESSING MOZBUILD FILE
==============================

The error occurred while processing the following file:

    /data/ports/firefox-30.0beta1/mozilla-beta/build/gyp.mozbuild

This file was included as part of processing:

    /data/ports/firefox-30.0beta1/mozilla-beta/media/libyuv/moz.build

The error was triggered on line 93 of this file:

    gyp_vars['target_arch'] = arches[CONFIG['CPU_ARCH']]

An error was encountered as part of executing the file itself. The error appears to be the fault of the script.

The error as reported by Python is:

    ["KeyError: u'sparc'\n"]
Reporter

Comment 1

5 years ago
Found it while building 30.0b1, still need to test m-a/m-c
Reporter

Comment 2

5 years ago
Obvious fix allows me to pass configure, but i dont know if it's neither correct nor if we  want to add more architectures there..
Reporter

Comment 3

5 years ago
Let's try this first, npotb and all that...
Assignee: nobody → landry
Attachment #8423192 - Flags: review?(mh+mozilla)
Assignee

Comment 4

5 years ago
Comment on attachment 8423192 [details] [diff] [review]
Add sparc64 & sparc

Review of attachment 8423192 [details] [diff] [review]:
-----------------------------------------------------------------

That sadly only addresses part of the problem. I have the same problem on s390x.
Attachment #8423192 - Flags: review?(mh+mozilla) → review-
Assignee

Comment 5

5 years ago
Let's just simplify the problem. Note this effectively means the value changes for ppc64, but no gyp file is checking for ppc anyways. This works for me on s390x and ppc.
Attachment #8424425 - Flags: review?(mshal)
Assignee

Updated

5 years ago
Assignee: landry → mh+mozilla
Status: NEW → ASSIGNED
Assignee

Updated

5 years ago
Attachment #8424425 - Flags: feedback?(landry)
Assignee

Updated

5 years ago
Reporter

Comment 6

5 years ago
Comment on attachment 8424425 [details] [diff] [review]
Use CPU_ARCH for unknown target_arch in gyp

Testing it on sparc64 & ppc - anyway, nothing checks for target_arch outside the tier1 archs so that should be fine.
Reporter

Comment 7

5 years ago
Comment on attachment 8424425 [details] [diff] [review]
Use CPU_ARCH for unknown target_arch in gyp

still building, but at least it went past the configure step, so that should be good to go.
Attachment #8424425 - Flags: feedback?(landry) → feedback+
Attachment #8424425 - Flags: review?(mshal) → review+
Assignee

Comment 9

5 years ago
Comment on attachment 8424425 [details] [diff] [review]
Use CPU_ARCH for unknown target_arch in gyp

[Approval Request Comment]
Bug caused by (feature/regressing bug #): regression from a combination of bug 778236 and the use of libyuv on builds without webrtc.
User impact if declined: Failure to build on non-mainstream architectures
Testing completed (on m-c, etc.): Tested on Debian builds. Landed on m-i today.
Risk to taking this patch (and alternatives if risky): Low. It changes how the target_arch gyp variable is deducted from the value of CPU_ARCH from our build system, which, in practice doesn't change the value for tier-1 platforms. Note that technically, this is almost NPOTB, but since it *does* change how the value is derived for android builds (but not the derived value itself, I'm requesting approval here, instead of using the blanket a=npotb)
String or IDL/UUID changes made by this patch: None
Attachment #8424425 - Flags: approval-mozilla-beta?
Attachment #8424425 - Flags: approval-mozilla-aurora?
Comment on attachment 8424425 [details] [diff] [review]
Use CPU_ARCH for unknown target_arch in gyp

Checked on inbound and this looks good so approving now in order to make sure it's in the landing queue for tomorrow's beta.
Attachment #8424425 - Flags: approval-mozilla-beta?
Attachment #8424425 - Flags: approval-mozilla-beta+
Attachment #8424425 - Flags: approval-mozilla-aurora?
Attachment #8424425 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/130e6eec39c4
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Whiteboard: [qa-]

Updated

Last year
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.