Closed Bug 1045231 Opened 5 years ago Closed 5 years ago

Build error on Yosemite: media/mtransport/third_party/nrappkit/src/util/byteorder.h:42:7: error: conflicting types for '__builtin_constant_p'

Categories

(Core :: WebRTC: Networking, defect)

x86
macOS
defect
Not set

Tracking

()

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

People

(Reporter: akachkach, Assigned: rillian)

References

Details

Attachments

(2 files, 1 obsolete file)

Attached file buildlogs3
Related to bug 1044497
Component: Video/Audio → WebRTC: Networking
This is the same like Bug 1035456, is it (but with a much more meaningful bug title)?
I think this is just one of the build errors we currently have on Yosemite (the first one I got after the fix in bug 1044497)
Yes, I also think there will be some more. But Bug 1035456 is only about the same error like this bug, so we can resolve one as duplication. Or transform Bug 1035456 into a metabug for all bugs related to 10.10 SDK.
This is just a quick ifdef hack to unbreak the build. There's probably a better fix in the gypfiles somewhere, since other platforms manage to build without duplicate htonll, ntohll.
Attachment #8472626 - Flags: review?(adam)
This seems to be the wrong syntax, because it's not working for me.
The good thing is, this seems to be the last 10.10 error. Because, if I delete everything inside the ifdef, I can build without any error with the 10.10 SDK (I have not tried "enable-target 10.10", maybe there will some too).
Attachment #8472626 - Attachment is patch: true
Great! I hope this lands soon :) (currently stuck on Yosemite, and can't test mochitest locally)
Comment on attachment 8472626 [details] [diff] [review]
Use system byteorder functions on MacOS X 10.10 and later.

Review of attachment 8472626 [details] [diff] [review]:
-----------------------------------------------------------------

I'm worried about using OS version as a proxy for "is this macro defined?" when you can simply check for macro definition locally. In particular, I'm worried that this may leave htonll undefined under certain combinations of compilers (or cross compilers) and target OS versions. This probably doesn't matter too much for moz code, but I'm worried about breaking things when we push our patches upstream.

Please use "#ifndef htonll" around the htonll declaration and definition, and "#ifndef ntohll" around ntohll.
Attachment #8472626 - Flags: review?(adam) → review-
Per irc discussion, here's a better fix. Just namespace the function names to avoid conflict, since they're only used within mtransport/third_party.

I didn't update the upstream diff; let me know if I need to do that.
Assignee: nobody → giles
Attachment #8472626 - Attachment is obsolete: true
Attachment #8473094 - Flags: review?(adam)
Comment on attachment 8473094 [details] [diff] [review]
Namespace nrAppKit's htonll function

Review of attachment 8473094 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!
Attachment #8473094 - Flags: review?(adam) → review+
This patch fixes my build errors, but I still get this when running mochitest:

1 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

I don't have a custom mozconfig and never got this error before upgrading to yosemite.
(In reply to Ahmed Kachkach [:akachkach] from comment #11)
> This patch fixes my build errors, but I still get this when running
> mochitest:
> 
> 1 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

I'd be curious to know the output of the following commands:

> file "/Users/akachkach/workspace/gecko-dev/obj-x86_64-apple-darwin14.0.0/dist/Nightly.app/Contents/MacOS/firefox"

and

> uname -a
(In reply to Adam Roach [:abr] from comment #12)
> 
> I'd be curious to know the output of the following commands:
> 
> > file "/Users/akachkach/workspace/gecko-dev/obj-x86_64-apple-darwin14.0.0/dist/Nightly.app/Contents/MacOS/firefox"
> 

/Users/akachkach/workspace/gecko-dev/obj-x86_64-apple-darwin14.0.0/dist/Nightly.app/Contents/MacOS/firefox: Mach-O 64-bit executable x86_64

> and
> 
> > uname -a

Darwin akachkach.local 14.0.0 Darwin Kernel Version 14.0.0: Wed Jul 16 00:46:31 PDT 2014; root:xnu-2782.1.43.0.2~2/RELEASE_X86_64 x86_64
BTW, I can run the executable (I get some errors in the console, but they're probably unrelated: https://pastebin.mozilla.org/5981241)
(In reply to Ahmed Kachkach [:akachkach] from comment #13)
> (In reply to Adam Roach [:abr] from comment #12)
> > 
> > I'd be curious to know the output of the following commands:
> > 
> > > file "/Users/akachkach/workspace/gecko-dev/obj-x86_64-apple-darwin14.0.0/dist/Nightly.app/Contents/MacOS/firefox"
> > 
> 
> /Users/akachkach/workspace/gecko-dev/obj-x86_64-apple-darwin14.0.0/dist/
> Nightly.app/Contents/MacOS/firefox: Mach-O 64-bit executable x86_64
> 
> > and
> > 
> > > uname -a
> 
> Darwin akachkach.local 14.0.0 Darwin Kernel Version 14.0.0: Wed Jul 16
> 00:46:31 PDT 2014; root:xnu-2782.1.43.0.2~2/RELEASE_X86_64 x86_64

Okay, so this is clearly a different problem. Go ahead and open a new bug on this problem (as was suggested in Bug 1044497 comment 10).
I filed bug 1054043 for this issue.
https://hg.mozilla.org/mozilla-central/rev/72dd2867fda3
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Flags: qe-verify-
[Tracking Requested - why for this release]:
Build bustage fix for MacOS Yosemite should be checked in on the esr branch.

Note this fix is necessary but not sufficient.  See bug 1044497.
Duplicate of this bug: 1035456
Comment on attachment 8473094 [details] [diff] [review]
Namespace nrAppKit's htonll function

Requesting ESR31 uplift, since this bug prevents local compilation of esr31 on OSX Yosemite.
Attachment #8473094 - Flags: approval-mozilla-esr31?
Attachment #8473094 - Flags: approval-mozilla-esr31? → approval-mozilla-esr31+
Blocks: 1159706
You need to log in before you can comment on or make changes to this bug.