Created attachment 330864 [details] fix Sources under comm-esr10/mozilla/ipc/chromium/src/base are expecting some includes that they shouldn't, should be including <unistd.h>, causes build breakage on gcc 4.7.x, where the inclusion of unistd.h in some other headers is fixed. (C specifications says that compiler/libc may include other headers, but that you shouldn't depend upon those -- don't remember the exact section of spec) /tmp/portage/mail-client/thunderbird-10.0.10/work/comm-esr10/mozilla/ipc/chromium/src/base/file_util.cc: In function 'bool file_util::TruncateFile(FILE*)': /tmp/portage/mail-client/thunderbird-10.0.10/work/comm-esr10/mozilla/ipc/chromium/src/base/file_util.cc:228:35: error: 'ftruncate' was not declared in this scope make[6]: *** [file_util.o] Error 1
Related upstream bug (attached patch in link below doesn't fix all of it however): https://bugzilla.mozilla.org/show_bug.cgi?id=706724
Oh, actually the patch below is a more portable fix for file_util.cc: https://bugzilla.mozilla.org/attachment.cgi?id=580642
Created attachment 330868 [details, diff] composite patch from upstream OK, here we go. There is a separate bug report that addresses the other three files, so here are both of the upstream bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=706724 https://bugzilla.mozilla.org/show_bug.cgi?id=725655 I've grabbed the patches from upstream and combined them. It would be good to cherry-pick these into 10.0.10-r1 or some such.
hmm, same problem with firefox-10.0.10. Note that these are the versions which are stable on amd64 (I haven't tried the ~amd64 versions currently in the tree)
Sorry for the multiple comments. But I've confirmed that this problem also exists in firefox & thunderbird versions 10.0.11. Thus, probably good to backport patch to all four (unless 10.0.11 is going stable very soon).
version 17 is next esr release, it will be stable long before gcc-4.7 is marked stable.
Well, incidentally, I've had very few problems building my system with gcc 4.7. I guess my philosophies don't match up with Gentoo's very closely. I feel that when a fix for "unsupported" interoperability (in this case, gcc 4.7) is easy and somebody wants to do it, that it's worth it integrate the fixes, but not to try to fix all such scenarios (obviously, that will never end) and implement some type of cut-off when complexity of such a fix rises to a certain level. *sigh* Oh well
it's just a bit of a lost cause, because #1 we apply stuffs after upstream at least ACKs on it, and #2 FF17 is imminent (and for that matter is already "old news" upstream). We're trying to prep FF17 et. al. so that it can be ready and stabilized asap, to get not only this but all the other goodies too. If FF17 was months away, then certainly this effort would be considered.
(In reply to comment #8) ahh, that makes sense. I guess I walk into this by mixing stable & unstable flags, but after working on some code who's performance was critical and closely examining the output of various versions of gcc, I really wanted to rebuild my system with gcc 4.7 (lots of goodies), so it's my fault, even though I blame you. ;) On a side note, of the 1500-ish packages I have installed, only about 5 or 6 of them had gcc 4.7-related build breakages (including firefox & thunderbird) a few of which were fixed with the unstable keyword. But I've sworn off ever running a fully unstable system again, I did it for four years that that's enough for me :) thanks for the reply!
