360583 - Don't define uint32 on OS X when security headers are included

Status: RESOLVED WONTFIX

(Camino Graveyard :: General, defect)

Description

[Stuart Morgan]

We currently can't use Security.framework on the branch because we end up with uint32 type conflicts from protypes.h

Comment 1

[Stuart Morgan]

Attachment: one approach

This will not define it if we have included the header that it conflicts with.

Comment 2

[Stuart Morgan]

This is trunk too; I was mistaken.

Comment 3

[Mike Pinkerton (not reading bugmail)]

cc'ing wtc for NSPR stuffs. wan-teh, does this seem reasonable?

Comment 4

[Stuart Morgan]

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.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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)?

Comment 6

[Wan-Teh Chang]

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 7

[Stuart Morgan]

Comment on attachment 245466 [details] [diff] [review]
one approach

-DNO_NSPR_10_SUPPORT works like a charm, thanks!

Comment 8

[Stuart Morgan]

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!