This breaks compilation of libsrtp in webrtc

I'm not totally sure what's going on here. Waldo did all the work with mozilla/StdInt.h, so maybe he has a clue.

This is why (I think) we have problems on windows (configure.in) # Check for headers defining standard int types. MOZ_CHECK_HEADERS(stdint.h inttypes.h sys/int_types.h) if test "$MOZ_TREE_CAIRO"; then AC_DEFINE(MOZ_TREE_CAIRO) # For now we assume that we will have a uint64_t available through # one of the above headers or mozstdint.h. AC_DEFINE(HAVE_UINT64_T) But honestly I haven't verified why it's defined (and my Win32 build env got trashed and I'm trying to restore it). We end up with #define HAVE_UINT64_t set in mozilla-config.h, which is simply wrong. This is the code from libsrtp (integers.h): /* Can we do 64 bit integers? */ #ifndef HAVE_UINT64_T # if SIZEOF_UNSIGNED_LONG == 8 typedef unsigned long uint64_t; # elif SIZEOF_UNSIGNED_LONG_LONG == 8 typedef unsigned long long uint64_t; # else # define NO_64BIT_MATH 1 # endif #endif If I remove the #ifndef HAVE_UINT64_T, it works. Since we should not be setting that if uint64_t isn't defined, then we should change configure.in (and any repercussions of that).

Yeah, probably getting rid of HAVE_UINT64_T is the right thing to do, then using mozilla/StandardInteger.h (name change needed for various obscure reasons) to get the type.

I can modify libsrtp if I need to, but it's normally set up to take a bunch of #defines (like HAVE_UINT64_T) which are output from configure (HAVE_STDINT_H, etc). If we fix HAVE_UINT64_T to be correct, libsrtp will be fine as-is - it's actually pretty portable, even to weirdo DSPs like the TI DM642 with 40-bit longs (I added the code to make that work - NO_64BIT_MATH above). So, what does it take to fix configure.in (and any code affected by that change)? Why does Cairo demand this even when the type doesn't exist? How does that work?

(In reply to Jeff Walden (:Waldo) (remove +bmo to email) from comment #3) > Yeah, probably getting rid of HAVE_UINT64_T is the right thing to do, then > using mozilla/StandardInteger.h (name change needed for various obscure > reasons) to get the type. As mentioned it's painful to modify imported code to do this; if you're referring to Cairo then this makes sense. I think the entire problem is due to the Cairo bit in configure forcing it.

I can probably fix this the right way, I had to do something similar for a bunch of other third-party code.

Is this still valid now that we require stdint.h?

kludge was removed long ago