734859 - uint64_t not defined on windows, but HAVE_UINT64_T is set by configure

Status: RESOLVED INVALID

(Core :: WebRTC, defect)

Description

[Randell Jesup [:jesup] (needinfo me)]

This breaks compilation of libsrtp in webrtc

Comment 1

[(not currently active) Ted Mielczarek]

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.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 3

[Jeff Walden [:Waldo]]

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.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

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?

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Attachment: better kludge until this is fixed

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

(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.

Comment 7

[(not currently active) Ted Mielczarek]

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

Comment 8

[Nathan Froyd [:froydnj]]

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

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

kludge was removed long ago