Closed Bug 1005449 Opened 10 years ago Closed 10 years ago

Missing archs in build/gyp.mozbuild

Categories

(Firefox Build System :: General, defect)

Sun
OpenBSD
defect
Not set
normal

Tracking

(firefox30 fixed, firefox31 fixed, firefox32 fixed)

RESOLVED FIXED
mozilla32
Tracking Status
firefox30 --- fixed
firefox31 --- fixed
firefox32 --- fixed

People

(Reporter: gaston, Assigned: glandium)

References

Details

(Whiteboard: [qa-])

Attachments

(3 files)

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"]
Found it while building 30.0b1, still need to test m-a/m-c
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..
Let's try this first, npotb and all that...
Assignee: nobody → landry
Attachment #8423192 - Flags: review?(mh+mozilla)
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-
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: landry → mh+mozilla
Status: NEW → ASSIGNED
Attachment #8424425 - Flags: feedback?(landry)
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.
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+
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: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Whiteboard: [qa-]
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.