Closed Bug 1044497 Opened 10 years ago Closed 10 years ago

Error building nsChildView.mm on OS X 10.10 (Yosemite) -- cannot initialize a parameter of type 'NSEventType' with an lvalue of type 'uint32_t'

Categories

(Core :: Widget: Cocoa, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla34
Tracking Status
firefox34 --- fixed
firefox-esr31 34+ fixed

People

(Reporter: akachkach, Assigned: smichaud)

References

Details

Attachments

(5 files)

Attached file execlogs —
I compiled Firefox Mac OS X Yosemite's preview, and got this error when trying to run mochitests: 1890 INFO runtests.py | Running tests: start. 1891 INFO runtests.py | Application pid: 45870 1892 INFO arch: posix_spawnp: /Users/akachkach/workspace/gecko-dev/obj-x86_64-apple-darwin14.0.0/dist/Nightly.app/Contents/MacOS/firefox: Bad CPU type in executable TEST-INFO | Main app process: killed by SIGHUP 1893 INFO TEST-UNEXPECTED-FAIL | automation.py | application terminated with exit code 1 1894 INFO runtests.py | Application ran for: 0:00:00.007492 1895 INFO zombiecheck | Reading PID log: /var/folders/d8/dn7q5bvx0r3_qwzh8nqy2sr40000gn/T/tmpJTS922pidlog If I try to run the executable directly, it runs (and tries to open some JSM file somehow...) but gives some warnings (see attached file). Also attached are the compile logs.
Attached file compilerlogs —
Attached file buildlogs2 —
After pulling and trying to re-compile, the compilation stopped after getting too many warnings (see logs)
I suspect Firefox may not have built correctly, even the first time. Did you use Apple's latest version of XCode for Yosemite? Did you install its latest version of the XCode commandline tools? What mozconfig did you use to build Firefox? What version Mavericks are you using? (What's the build id?) Are you building from current trunk (mozilla-central) code?
Finally, if you are able to build on another version of OS X (with the same mozconfig and the same version of trunk code), please do so. You may find that you see the same errors.
(In reply to Steven Michaud from comment #3) > I suspect Firefox may not have built correctly, even the first time. > > Did you use Apple's latest version of XCode for Yosemite? Did you install > its latest version of the XCode commandline tools? > No, I have XCode 5, currently downloading XCode 6 beta to see if that solves the problem. Might this be related to the commandline tools? They don't have them for Yosemite, and I'm wondering if the mavericks one can still be used with yosemite. > What mozconfig did you use to build Firefox? > I usually just run "mach configure", but I tried using this config: https://developer.mozilla.org/en-US/docs/Configuring_Build_Options#Firefox.2C_Default_Release_Configuration and got the same error. > What version Mavericks are you using? (What's the build id?) > I'm currently using Yosemite: System Version: OS X 10.10 (14A299l) Kernel Version: Darwin 14.0.0 I could compile Firefox without any issues when I was on Mavericks. > Are you building from current trunk (mozilla-central) code? Yes.
> Might this be related to the commandline tools? They don't have them for Yosemite Actually Apple does have them. I see "Command Line Tools (OS X 10.10) for XCode (Late July 2014)" listed among the downloads available from the Mac Member Center. If you can't get them any other way, I believe it's possible to install the Command Line Tools from inside the appropriate version of XCode (in your case the XCode 6 that you just downloaded).
After installing the new XCode (XCode 6 beta4), switching to it with xcode-select, and installing the new command line tools, I still have the same error: 1:53.37 /Users/akachkach/workspace/gecko-dev/widget/cocoa/nsChildView.mm:1481:48: error: cannot initialize a parameter of type 'NSEventType' with an lvalue of type 'uint32_t' (aka 'unsigned int') 1:53.37 NSEvent* event = [NSEvent mouseEventWithType:aNativeMessage 1:53.37 ^~~~~~~~~~~~~~ 1:53.37 /System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h:431:46: note: passing argument to parameter 'type' here 1:53.37 + (NSEvent *)mouseEventWithType:(NSEventType)type location:(NSPoint)location modifierFlags:(NSEventModifierFlags)flags timestamp:(NSTimeInterval)time windowNumber:(NSInteger)wNum context:(NSGraphicsContext*)context eventNumber:(NSInteger)eNum clickCount:(NSInteger)cNum pressure:(float)pressure; 1:53.37 ^ 1:53.47 Warning: -Wswitch in /Users/akachkach/workspace/gecko-dev/widget/cocoa/nsChildView.mm: 22 enumeration values not handled in switch: 'NSMouseMoved', 'NSMouseEntered', 'NSMouseExited'... 1:53.47 /Users/akachkach/workspace/gecko-dev/widget/cocoa/nsChildView.mm:5367:11: warning: 22 enumeration values not handled in switch: 'NSMouseMoved', 'NSMouseEntered', 'NSMouseExited'... [-Wswitch] 1:53.47 switch ([aMouseEvent type]) { 1:53.47 ^ 1:53.47 Warning: -Wdeprecated-declarations in /Users/akachkach/workspace/gecko-dev/widget/cocoa/nsChildView.mm: 'insertText:' is deprecated: first deprecated in OS X 10.6 1:53.47 /Users/akachkach/workspace/gecko-dev/widget/cocoa/nsChildView.mm:5413:9: warning: 'insertText:' is deprecated: first deprecated in OS X 10.6 [-Wdeprecated-declarations] 1:53.47 [self insertText:@"\n"]; 1:53.47 ^ 1:53.47 /System/Library/Frameworks/AppKit.framework/Headers/NSInputManager.h:18:1: note: 'insertText:' has been explicitly marked deprecated here 1:53.47 - (void) insertText:(id)aString NS_DEPRECATED_MAC(10_0, 10_6); // instead of keyDown: aString can be NSString or NSAttributedString 1:53.47 ^ 1:53.48 nsAppStartupNotifier.o 1:53.64 2 warnings and 1 error generated. ...
So this is really a build error. Seems like Clang is getting pickier. Shouldn't be hard to fix. Patch coming up. Please try it after I post it (to see if there are other build errors, which might also be easy to fix).
Summary: Can't run tests on firefox compiled on Mac OS X Yosemite → Error building nsChildView.mm on OS X 10.10 (Yosemite)
Component: General → Widget: Cocoa
Product: Firefox → Core
Summary: Error building nsChildView.mm on OS X 10.10 (Yosemite) → Error building nsChildView.mm on OS X 10.10 (Yosemite) -- cannot initialize a parameter of type 'NSEventType' with an lvalue of type 'uint32_t'
Attached file Fix —
Try this patch and see if it helps.
Assignee: nobody → smichaud
If you continue to have problems running tests, open another bug for that.
By the way (if you didn't already know it), our tests are *very* finicky. I expect *many* of them to fail with builds made on Yosemite.
Attached file buildlogs3 —
The patch fixed the first error I got, but I got a bunch of other errors after a couple minutes (see logs attached)
The next build error is this: media/mtransport/third_party/nrappkit/src/util/byteorder.h:42:7: error: conflicting types for '__builtin_constant_p' Please open a separate bug on it. And do the same with whatever other build errors you find. We can worry about the warnings later.
A general word of advice: Firefox *always* has build errors on new major versions of OS X when they first appear. Some of them are easier to fix than others, but it will take weeks to find and fix them all. So unless you want to help us find and fix these errors, it's currently best not to do Firefox development work on Yosemite. Build instead on earlier versions of OS X, and then (if you wish) *run* these builds on Yosemite.
Attachment #8463565 - Flags: review?(spohl.mozilla.bugs)
Attachment #8463565 - Flags: review?(spohl.mozilla.bugs) → review+
I think those should be fixed anyway, Yosemite should be released early this fall (the public beta is pretty stable and almost all apps are already finished). I wouldn't mind fixing those if I had any idea what those errors are :) I'm not really familiar with the gecko codebase unfortunately (I mostly work on mochitests). If one of the Mac developers is using the Yosemite preview it might be easier to fix those errors, but otherwise I don't mind testing any patches and filing bugs.
Most of the errors are usually in non-Mac-specific code. You just need to have lots of experience doing your own builds of *any* software on a new platform, and deciphering the the inevitable build errors. I'm usually the one who ends up fixing most of them. But I've currently got too much other stuff on my plate, so I'm going to put that off for a few weeks. Others deserve the chance to try first :-)
Using the MacOSX 10.8 SDK makes it possible to compile firefox without any errors, but it's impossible to launch mochitests because of this error: "1892 INFO arch: posix_spawnp: /Users/akachkach/workspace/gecko-dev/obj-x86_64-apple-darwin14.0.0/dist/Nightly.app/Contents/MacOS/firefox: Bad CPU type in executable" Here's the mozconfig used for this (tried to copy some parts that are supposed to produce a "universal binary", but it's not working really well): . $topsrcdir/browser/config/mozconfig . $topsrcdir/build/macosx/universal/mozconfig ac_add_options --with-macos-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk mac
Flags: needinfo?(smichaud)
What you say in comment #17 isn't relevant to the rest of this bug. You probably need to do a universal build of Firefox, using something like this mozconfig file: bug 773905 comment #62 The "standard" ways of doing universal builds, as described on various mozilla.org sites, no longer work outside Mozilla's own releng infrastructure. This happened as of the patch for bug 773905, and very unfortunately doesn't seem to be documented anywhere else.
Flags: needinfo?(smichaud)
Oops, that's bug 733905 (not 773905).
Blocks: 1047486
Oops, forgot to land this on mozilla-inbound? Will do that now. But how on earth does bug 1047486 depend on this bug?
Thanks. bug 1047486 is 10.10 specific; it's easier to debug if I can build master.
You may find it easier to build with the 10.9 SDK than with the 10.10 SDK (or no SDK at all, which is the equivalent of building with the 10.10 SDK).
In any case, as I said above, there are *always* build problems on new major versions of OS X, and they won't all be as easy as this one, or get fixed as quickly. Ultimately you may need to build on OS X 10.9 and test on Yosemite, until all the build problems are fixed. That's what I do. I make the process easier by installing multiple versions of OS X on different partitions on the same machine. Then I use "ln -s" to make the build directories have the same path booted from any partition. For example, I create /usr/local/src/Mozilla on my "main" partition, and create soft links to it at /usr/local/src/ in the other partitions.
Oops, mozilla-inbound just closed :-( That's why I didn't land this patch immediately after spohl reviewed it -- it was closed then, too. I'll try again tomorrow.
Ralph, I think you'll find that you still can't build with the 10.10 SDK, even with this patch landed. Apple's headers seem to have changed with the 10.10 SDK and it's causing a bunch of problems, not just for our project. I was pulled into a different direction before I could investigate in detail, but thought I'd throw this out there.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
(In reply to Stephen Pohl [:spohl] from comment #25) > Ralph, I think you'll find that you still can't build with the 10.10 SDK, > even with this patch landed. Well yes, but we have to get this working eventually; I thought I'd hurry things along while I was here. My 10.8 builds also crash on startup on 10.10, and this was easier to debug... :-) Thanks for landing the patch!
Ralph: Please open a new (separate) bug for each build problem you find. And extra credit for posting a fix! Ask review from either Stephen or me, and if necessary we'll pass the review request along to someone else. (Note that I'll be on vacation next week, and away from the web.)
[Tracking Requested - why for this release]: Build bustage fix for MacOS Yosemite should be checked in on the esr branch.
Comment on attachment 8463565 [details] Fix Need this to compile esr31 locally on Yosemite.
Attachment #8463565 - Flags: approval-mozilla-esr31?
[Tracking Requested - why for this release]:
Attachment #8463565 - Flags: approval-mozilla-esr31? → approval-mozilla-esr31+
Blocks: 1159706
Did this regress? I'm seeing it again while building. "3:09.92 Warning: -Wdeprecated-declarations in /Users/marcos/gecko/widget/cocoa/nsChildView.mm: 'insertText:' is deprecated: first deprecated in OS X 10.6"
(In reply to Marcos Caceres [:marcosc] from comment #34) > Did this regress? I'm seeing it again while building. > > "3:09.92 Warning: -Wdeprecated-declarations in > /Users/marcos/gecko/widget/cocoa/nsChildView.mm: 'insertText:' is > deprecated: first deprecated in OS X 10.6" This is a warning, not an error. The patch here made no claim to fix this warning.
(In reply to Stephen A Pohl [:spohl] from comment #35) > This is a warning, not an error. The patch here made no claim to fix this > warning. True, but isn't this a time-bomb waiting to happen? Or is it not worth worrying about the deprecated APIs until they are actually removed?
(In reply to Marcos Caceres [:marcosc] from comment #36) > (In reply to Stephen A Pohl [:spohl] from comment #35) > > This is a warning, not an error. The patch here made no claim to fix this > > warning. > > True, but isn't this a time-bomb waiting to happen? Or is it not worth > worrying about the deprecated APIs until they are actually removed? I should have answered your question in comment 34 more directly: no, this bug did not regress. You're welcome (and encouraged) to file bugs for any other build errors/warnings that you encounter, but they will not be addressed in this bug here.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: