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

RESOLVED INVALID

Status

()

RESOLVED INVALID
7 years ago
3 years ago

People

(Reporter: jesup, Assigned: ted)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [WebRTC], [blocking-webrtc-])

Attachments

(1 attachment)

(Reporter)

Description

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

Comment 2

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

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

Comment 4

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

Comment 5

7 years ago
Created attachment 606838 [details] [diff] [review]
better kludge until this is fixed
(Reporter)

Comment 6

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

Updated

6 years ago
QA Contact: jsmith
I can probably fix this the right way, I had to do something similar for a bunch of other third-party code.
Assignee: nobody → ted.mielczarek

Updated

6 years ago
Whiteboard: [WebRTC], [blocking-webrtc-]
Is this still valid now that we require stdint.h?
(Reporter)

Comment 9

3 years ago
kludge was removed long ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.