Centos 6.3 Build Error: "conflicting types for ‘UTP_Write’"

[cfpp2p]

cfpp2p@39d0263

This bug was submitted by mmain Transmission ticket #5232 I'm passing it upstream.

---

I have been successfully using Transmission on Centos 5.8, but now need to
 upgrade to Centos 6.3 and have started building new machine with 6.3 loaded
 and I am unable to build Transmission from source without following error
 during make(I also tried 2.75 with same
result)

tr-utp.c:65: error: conflicting types for ‘UTP_Write’
../third-party/libutp/utp.h:116: note:
 previous declaration of ‘UTP_Write’ was here

make[1]: * [tr-utp.o] Error 1
make[1]: Leaving directory `/root/transmission-2.76/libtransmission'
make: * [all-recursive] Error 1

...

Changed 16 hours ago by x190

UTP_Write() is type bool. Maybe utp.h needs the following bit of voodoo that
 was added to transmission.h.

#if !defined (__cplusplus)
 #ifdef HAVE_STDBOOL_H
  #include <stdbool.h>
 #elif !defined (__bool_true_false_are_defined)
  #define bool uint8_t
  #define true 1
  #define false 0
 #endif
#endif


comment:5 Changed 13 hours ago by mmain

Yes, this worked a treat. Many Thanks


comment:6 Changed 12 hours ago by jordan

x190: that's the great idea, you ought to submit that upstream to the
 libutp project on github.

[cfpp2p]

cfpp2p@39d0263

[ghazel]

bool is defined (conditionally) in utypes.h not utp.h. So that's one thing to address first.

Next, what is __bool_true_false_are_defined? Finally, utp.cpp itself is C++ obviously, so there's no pressing need to define true and false in the header.

[jordanl]

__bool_true_false_are_defined is a macro from stdbool.h to detect whether those keywords have already been defined.

The issue is that the compiler isn't smart enough to understand that the different typedefs from utypes.h, stdbool.h, and elsewhere are really the same unsigned char, so compilation fails with a mismatch.

Including stdbool.h in the not-C++ block of utypes.h would fix this. I don't know how universal stdbool.h is on your target platforms, but you could possibly drop the HAVE_STDBOOL_H autoconf idiom.

[ghazel]

Certainly there is no stdbool.h on Windows. Also we don't have autoconf to set HAVE_STDBOOL_H.

Any easy answer here would be just use ints. That seems unlikely to bite me again (#12).

Why does the state of C89/C99/C++ have to be so terrible?

[jordanl]

Blah, I forgot about #12.

int sounds like it might be the least-bad choice.