Closed Bug 360583 Opened 15 years ago Closed 15 years ago
Don't define uint32 on OS X when security headers are included
We currently can't use Security.framework on the branch because we end up with uint32 type conflicts from protypes.h
This will not define it if we have included the header that it conflicts with.
Assignee: nobody → stuart.morgan
Status: NEW → ASSIGNED
Attachment #245466 - Flags: review?(mikepinkerton)
This is trunk too; I was mistaken.
cc'ing wtc for NSPR stuffs. wan-teh, does this seem reasonable?
Comment on attachment 245466 [details] [diff] [review] one approach Re-targeting review as suggested by pink. Basically, we're trying to include a new header that's giving us type conflicts, and we need to work around it somehow. If this isn't a good way, I'm definitely open to suggestions.
Attachment #245466 - Flags: review?(mikepinkerton) → review?(wtchang)
Is mozilla pulling the same NSPR tag on both the trunk and the MOZILLA_1_8_BRANCH (since we'd need this fix for Camino releases on both)?
The best way to avoid this problem is to compile the files in question with the -DNO_NSPR_10_SUPPORT flag. If the macro NO_NSPR_10_SUPPORT is defined, NSPR won't include protypes.h. Please try to compile your code with -DNO_NSPR_10_SUPPORT. Hopefully your code will just compile or only require minor changes. Is this Security framework header available under the standard system header directory (e.g., /usr/include), or do you need to specify a -I flag to locate it?
Comment on attachment 245466 [details] [diff] [review] one approach -DNO_NSPR_10_SUPPORT works like a charm, thanks!
Attachment #245466 - Flags: review?(wtchang)
The security header in question only comes if you link in Security.framework; it's not a base OS header. Since we know now the right way to work around this, closing WONTFIX. Thanks again for the help!
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.