If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED FIXED in Firefox 34

Status

()

Core
WebRTC: Networking
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: akachkach, Assigned: rillian)

Tracking

unspecified
mozilla34
x86
Mac OS X
Points:
---
Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox34 fixed, firefox-esr3134+ fixed)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

3 years ago
Created attachment 8463595 [details]
buildlogs3

Related to bug 1044497

Updated

3 years ago
Component: Video/Audio → WebRTC: Networking

Comment 1

3 years ago
This is the same like Bug 1035456, is it (but with a much more meaningful bug title)?
(Reporter)

Comment 2

3 years ago
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)

Comment 3

3 years ago
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.
(Assignee)

Comment 4

3 years ago
Created attachment 8472626 [details] [diff] [review]
Use system byteorder functions on MacOS X 10.10 and later.

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)

Comment 5

3 years ago
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).

Updated

3 years ago
Attachment #8472626 - Attachment is patch: true
(Reporter)

Comment 6

3 years ago
Great! I hope this lands soon :) (currently stuck on Yosemite, and can't test mochitest locally)

Comment 7

3 years ago
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-
(Assignee)

Comment 8

3 years ago
Created attachment 8473094 [details] [diff] [review]
Namespace nrAppKit's htonll function

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 9

3 years ago
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+
https://hg.mozilla.org/integration/mozilla-inbound/rev/72dd2867fda3
(Reporter)

Comment 11

3 years ago
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.

Comment 12

3 years ago
(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
(Reporter)

Comment 13

3 years ago
(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
(Reporter)

Comment 14

3 years ago
BTW, I can run the executable (I get some errors in the console, but they're probably unrelated: https://pastebin.mozilla.org/5981241)

Comment 15

3 years ago
(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
Last Resolved: 3 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.
tracking-firefox-esr31: --- → ?
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+
https://hg.mozilla.org/releases/mozilla-esr31/rev/e7b6eb1f8484
status-firefox34: --- → fixed
status-firefox-esr31: --- → fixed
tracking-firefox-esr31: ? → 34+

Updated

2 years ago
Blocks: 1159706
You need to log in before you can comment on or make changes to this bug.