Closed Bug 825840 Opened 7 years ago Closed 7 years ago
[build] Mac Gecko build an flash are broken
STR: 0- On a Mac 1- ./repo sync 2- ./build.sh 3- ./flash.sh Expected: Unagi starts with fresh build Actual: the unagi starts but the screen stays black.
Assignee: nobody → doug.turner
blocking-basecamp: --- → ?
From Anthony Ricaud on the mailing list: It seems the root error is this: $ "/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.8.0 -syslibroot /Users/rik24d/code/b2g-unagi/**out/target/product/unagi/obj/ -o a.out -L/Users/rik24d/code/b2g-**unagi/out/target/product/**unagi/obj/lib -rpath-link=/Users/rik24d/**code/b2g-unagi/out/target/**product/unagi/obj/lib -lSystem /usr/bin/../lib/clang/4.0/lib/**darwin/libclang_rt.osx.a ld: unknown option: -rpath-link=/Users/rik24d/**code/b2g-unagi/out/target/ **product/unagi/obj/lib Does ld on the Mac not have the rpath-link option?
Andrew: Looks like it doesn't. Here's the output of `ld -v` : @(#)PROGRAM:ld PROJECT:ld64-133.3 configured to support archs: armv6 armv7 i386 x86_64 LTO support using: LLVM version 3.1svn, from Apple Clang 4.0 (build 421.0.60) I'm on 10.8.2.
Very important to fix, but not a blocker. Adding some who may have an idea where to look.
blocking-basecamp: ? → -
I have the same ld. Not sure what to add, but yes, ld64 has -rpath, but no -rpath-link. From the manual it looks like -rpath just changes the runtime behaviour, not the link time one as with ELF.
i am not working on this.
Assignee: doug.turner → nobody
I'd like to renominate this as this seriously affects our development process. Not being able to build affects my productivity.
blocking-basecamp: - → ?
I second Anthony's comment. If this is not a blocking bug, then no one will fix it. And then all mac-based developers will be screwed. Bug 825698, for example, is a blocking+ bug assigned to me. I can't work on it because versions of gecko that I build will not boot. It probably isn't right to say that this bug blocks 825698, but it kind of does. I am currently the best person to work on 825698, but I can't.
These are the symptoms I see with this bug. My build process looks like this: ./build.sh gecko ./flash.sh gecko Both of these steps run without error. But then the phone won't boot. It shows the FirefoxOS splash screen, but then goes black. Building m-c from the tip yesterday, the errors in logcat were in Webapps.jsm at line 2290, I think. (It was something about nsIProperties.get, but the code at line 2290 is completely unrelated to that). Sometimes I would also see repeated errors in OfflineCacheInstaller.jsm at line 68 where it calls outputStream.close(). The error message seems to indicate that output streams don't have close methods anymore, which seems sort of absurd. I've seen other bugs that mention recent necko changes... Could that be affecting anything here? I also tried building b2g18 from tip last night. I got the very same Webapps.jsm error, but didn't see any errors from OfflineCacheInstaller.jsm Then, I reverted b2g18 to right before the most recent (just a few days ago) change to Webapps.jsm. But I still saw the error in that file, only at a slightly different line number because of the change to the file. Maybe someone could bisect this?
As a start at the bisection, I'm trying hg checkout -d 2012-12-28 and will see if that builds and boots.
I should add that I'm on MacOS 10.6.8 and am not noticing any link errors when I build. I've got clang 3.1 installed, but I assume I'm using whatever stock version of ld is on the system.
I've attached the logcat output of a reboot up until the time the screen goes blank and the soft buttons illuminate. It shows the Webapps.jsm error, but does not show the OfflineCacheInstaller errors that occur on the restart after flashing
Doing hg checkout -d 2012-12-26 on my mozilla-central tree and rebuilding doesn't fix the problem either. That't pretty weird, since I'm almost positive I was building gecko successfully in that time frame.
See also bug 826445
See bug 826445 comment 5.
Assignee: nobody → philipp
JP suggested that Brad may be able to take a look.
Comment on attachment 697654 [details] [diff] [review] fix that doesn't Ok, never mind, this doesn't work after all. Weird, I'm pretty sure it was working just a minute ago. I bet we're now running into another weird import failure that simply isn't being logged.
(In reply to David Flanagan [:djf] from comment #11) > Notice the difference in the file URLs. Completly different URL schemes. I > have no idea what it means, but it seems like it could be a hint to someone > who understands it... I'd say that's because one is .jsm and the other is .js :) not the same files ! so you're not looking at the same error at all in both cases. Also, the line number is wrong because these files are preprocessed, you have to look around the said line number to find the guilty line.
As all Mac users are impacted, this is now considered as a blocker.
blocking-basecamp: ? → +
Priority: -- → P1
> Also, the line number is wrong because these files are preprocessed, you have to look around the > said line number to find the guilty line. One can just look at the file in the objdir. Anyway, we got the line in bug 826445.
(In reply to Julien Wajsberg [:julienw] from comment #21) > > I'd say that's because one is .jsm and the other is .js :) not the same > files ! so you're not looking at the same error at all in both cases. That's embarassing! Sorry for the noise!
Philip any news here? I am currently bisecting. The last good build was around 12/29.
I'll find and owner for this to offload :phillikon.
Assignee: philipp → milan
Gregor says the problem started somewhere around here - https://hg.mozilla.org/mozilla-central/pushloghtml?startID=24086&endID=24087
you can even use the releases/b2g18 repository, this might be easier.
It's caused by https://hg.mozilla.org/mozilla-central/rev/422309d2a072
Hub, the code change doesn't seem like something that should have caused the build to break, but are you around to take a look?
(In reply to Milan Sreckovic [:milan] from comment #30) > Hub, the code change doesn't seem like something that should have caused the > build to break, but are you around to take a look? I don't have a Mac build environment for b2g. I build in Fedora 17 as always. I don't see why my change who wreck havoc like that.
We have some problems importing resource://gre/modules/CrashSubmit.jsm and throw an exception here: https://hg.mozilla.org/mozilla-central/file/38407b98003b/b2g/chrome/content/shell.js#l84
blocking-basecamp: + → ?
Priority: P1 → --
(In reply to Philipp von Weitershausen [:philikon] from comment #33) > So somehow we're failing to Cu.import() things at seemlingly random times. Err nevermind, just saw comment 29.
Assignee: milan → anygregor
This got mistakenly non-plused.
blocking-basecamp: ? → +
Priority: -- → P1
Comment on attachment 698083 [details] [diff] [review] patch Review of attachment 698083 [details] [diff] [review]: ----------------------------------------------------------------- Ship it! We never include CrashSubmit.jsm when not building the crash reporter , so this seems like the right fix to me.  https://mxr.mozilla.org/mozilla-central/source/toolkit/Makefile.in#58 ::: b2g/chrome/content/shell.js @@ +85,5 @@ > Cu.import("resource://gre/modules/CrashSubmit.jsm", this); > return this.CrashSubmit; > +#else > + return null; > +#endif Micro-nit: move the `delete this.CrashSubmit;` out of the #ifdef and do `return this.CrashSubmit = null;` here, avoiding the getter later.
Attachment #698083 - Flags: review+
Attachment #697654 - Attachment is obsolete: true
So by re-reading this, here is the conclusion: I doubt it was Mac specific. It was indeed caused by an original bug in the original implementation of the crash report - bug that didn't conditionally load the crash submit module - but triggered by my change that cause the crash submit module to attempt to load even if no crash dump has been created. As usual I forgot I always force the inclusion of the crash reporter in my local build, and how could I forgot since after each time I do a |./repo sync| I have to reapply the patch. Sorry about that. Nice work !
hub, how do you explain that it worked on Linux ?
(In reply to Julien Wajsberg [:julienw] from comment #40) > hub, how do you explain that it worked on Linux ? On Linux in general I don't know, but on MY Linux, as I said, I build with the crash reporter opted in (a patch in gonk-misc is needed for that). Also the official builds are probably not having issues either as they do build with crash reporter.
But I'm not using this patch to build and I didn't have this problem on my Linux...
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
this must be in aurora too.
(In reply to Julien Wajsberg [:julienw] from comment #40) > hub, how do you explain that it worked on Linux ? The crashreporter code is not very cross-compile friendly (when the host and target OS are not the same, Linux->Android works fine). I believe the default B2G mozconfig disables the crashreporter when building on Mac OS X.
I'm actually still seeing the Webapps.jsm bug when I try to build mozilla-central, too. I'm using he ./build.sh gecko build script. Does this mean that the build script is misconfigured?
You should maybe try a full ./build.sh (without clobbering)
Please disregard comment 48. My .userconfig was messed up, and I was actually trying to build b2g18 again, before this patch was applied to that tree.
Building b2g18 works for me now.
(In reply to Julien Wajsberg [:julienw] from comment #46) > this must be in aurora too. Apparently it was decided this morning that uplifts only need to go on b2g18 now, so nothing else needs doing here.
You need to log in before you can comment on or make changes to this bug.