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)
Tracking
()
RESOLVED
FIXED
mozilla34
People
(Reporter: akachkach, Assigned: smichaud)
References
Details
Attachments
(5 files)
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.
Reporter | ||
Comment 1•10 years ago
|
||
Reporter | ||
Comment 2•10 years ago
|
||
After pulling and trying to re-compile, the compilation stopped after getting too many warnings (see logs)
Assignee | ||
Comment 3•10 years ago
|
||
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?
Assignee | ||
Comment 4•10 years ago
|
||
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.
Reporter | ||
Comment 5•10 years ago
|
||
(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.
Assignee | ||
Comment 6•10 years ago
|
||
> 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).
Reporter | ||
Comment 7•10 years ago
|
||
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.
...
Assignee | ||
Comment 8•10 years ago
|
||
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)
Assignee | ||
Updated•10 years ago
|
Component: General → Widget: Cocoa
Product: Firefox → Core
Assignee | ||
Updated•10 years ago
|
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'
Assignee | ||
Comment 10•10 years ago
|
||
If you continue to have problems running tests, open another bug for that.
Assignee | ||
Comment 11•10 years ago
|
||
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.
Reporter | ||
Comment 12•10 years ago
|
||
The patch fixed the first error I got, but I got a bunch of other errors after a couple minutes (see logs attached)
Assignee | ||
Comment 13•10 years ago
|
||
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.
Assignee | ||
Comment 14•10 years ago
|
||
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.
Assignee | ||
Updated•10 years ago
|
Attachment #8463565 -
Flags: review?(spohl.mozilla.bugs)
Updated•10 years ago
|
Attachment #8463565 -
Flags: review?(spohl.mozilla.bugs) → review+
Reporter | ||
Comment 15•10 years ago
|
||
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.
Assignee | ||
Comment 16•10 years ago
|
||
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 :-)
Reporter | ||
Comment 17•10 years ago
|
||
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)
Assignee | ||
Comment 18•10 years ago
|
||
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)
Assignee | ||
Comment 19•10 years ago
|
||
Oops, that's bug 733905 (not 773905).
Assignee | ||
Comment 20•10 years ago
|
||
Oops, forgot to land this on mozilla-inbound? Will do that now.
But how on earth does bug 1047486 depend on this bug?
Comment 21•10 years ago
|
||
Thanks. bug 1047486 is 10.10 specific; it's easier to debug if I can build master.
Assignee | ||
Comment 22•10 years ago
|
||
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).
Assignee | ||
Comment 23•10 years ago
|
||
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.
Assignee | ||
Comment 24•10 years ago
|
||
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.
Comment 25•10 years ago
|
||
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.
Assignee | ||
Comment 26•10 years ago
|
||
Comment on attachment 8463565 [details]
Fix
Landed on mozilla-inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2b1da8de6a91
Comment 27•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Comment 28•10 years ago
|
||
(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!
Assignee | ||
Comment 29•10 years ago
|
||
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.)
Comment 30•10 years ago
|
||
[Tracking Requested - why for this release]:
Build bustage fix for MacOS Yosemite should be checked in on the esr branch.
tracking-firefox-esr31:
--- → ?
Comment 31•10 years ago
|
||
Comment on attachment 8463565 [details]
Fix
Need this to compile esr31 locally on Yosemite.
Attachment #8463565 -
Flags: approval-mozilla-esr31?
Comment 32•10 years ago
|
||
[Tracking Requested - why for this release]:
Updated•10 years ago
|
Updated•10 years ago
|
Attachment #8463565 -
Flags: approval-mozilla-esr31? → approval-mozilla-esr31+
Updated•10 years ago
|
status-firefox-esr31:
--- → affected
Comment 33•10 years ago
|
||
status-firefox34:
--- → fixed
Comment 34•9 years ago
|
||
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"
Comment 35•9 years ago
|
||
(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.
Comment 36•9 years ago
|
||
(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?
Comment 37•9 years ago
|
||
(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.
Description
•