Closed Bug 965340 Opened 10 years ago Closed 8 years ago fails to build if <algorithm> is included in mfbt/FloatingPoint.h


(Firefox Graveyard :: Webapp Runtime, defect, P3)



(Not tracked)



(Reporter: kats, Unassigned)




(2 files)

On Mac OS X, adding #include <algorithm> to or anywhere in the include chain for that file causes compilation to fail. The specific compilation error is:

/Users/kats/zspace/mozilla-git/webapprt/mac/ error: unexpected '@' in program
  @try {

This is a problem because I would like to include <algorithm> in mfbt/FloatingPoint.h for bug 948984, and it causes this build error.

The other weird aspect to this is that when the build fails, it spits out the command that fails (an invocation of clang++ with various arguments). When I run this command manually it works just fine. The difference is that when run via the build system, the command is run through XCode's make (i.e. "/Applications/ compile") which sets an environment variable "MACOSX_DEPLOYMENT_TARGET=10.6" and this seems to be the cause of the difference. When I set that environment variable and run the clang++ command myself I can reproduce the failure.
This is the minimal patch to repro the problem for me locally. Try is closed so I haven't tested there yet but I strongly suspect it will be the case there as well. Myk was also able to repro with this patch.
Upon smichaud's suggestion, I added the following to my mozconfig and did a clobber build:

ac_add_options --with-macos-sdk=/Applications/
ac_add_options --enable-macos-target=10.8

However this did not fix the problem. (I suspected this might happen because when I run the clang++ command manually it fails when MACOSX_DEPLOYMENT_TARGET is set to 10.6, 10.7, or 10.8 - it only passes when I set it to 10.9).

If I change the --enable-macos-target to 10.9 then it will build webapprt.o but fail at link time.

If I keep only the --enable-macos-target=10.9 and remove the --with-macos-sdk option, then the build completes succesfully.
You shouldn't have to change the sdk and MACOSX_DEPLOYMENT_TARGET targets to get our "official" builds to work, and for many of those the setting is 10.6 (and should remain so as long as we continue to support OS X 10.6).

Please start a tryserver build once the tryservers reopen, and post a link to it here.
So yes, #including <algorithm> in is sufficient to break the build:
Thanks, kats, for persevering.  Now that you've demonstrated this isn't just a problem with how you set up your local build, we've got to figure out what to do about it.

Ted, are you willing to take this?  I can if you aren't, but I'm still going to ask :-)

And exactly how urgent is this?
Flags: needinfo?(ted)
It's not that urgent for me, since I found a workaround that didn't require #including <algorithm>
Flags: needinfo?(ted)
Oops, didn't mean to clear that, just wanted to CC some folks. I don't know that I want to own this, but I may be able to look at it.
Flags: needinfo?(ted)
We had to do a similar thing before, see attachment 691119 [details] [diff] [review].
Thanks, Ehsan!  For the record, that's from bug 786533.
Priority: -- → P3
Blocks: 1111077
Per bug 1238079, we're going to disable the desktop web runtime and remove it from the codebase, so we won't fix these bugs in it.
Closed: 8 years ago
Resolution: --- → WONTFIX
Flags: needinfo?(ted)
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.