Opened 10 years ago

Closed 7 years ago

#4528 closed Bug (incomplete)

bool error

Reported by: naddy Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.33+
Severity: Normal Keywords: bool, utp
Cc: blakawk@…, vincent.riera@…

Description

On OpenBSD, 2.40b2 fails to compile:

tr-utp.c:66: error: conflicting types for 'UTP_Write' ../third-party/libutp/utp.h:116: error: previous declaration of 'UTP_Write' was here

The problem is that the utp.h declaration of UTP_Write() happens before, but the tr-utp.c one after including <stdbool.h> from transmission.h. (OpenBSD's stdbool.h declares a type _Bool and defines bool to _Bool.)

This was fine in 2.33, but @12663 broke it. Something like the attached patchlet is necessary.

Attachments (1)

patch-third-party_libutp_utypes_h (323 bytes) - added by naddy 10 years ago.

Download all attachments as: .zip

Change History (17)

Changed 10 years ago by naddy

comment:1 Changed 10 years ago by jordan

Naddy, the patch looks fine but you need to report it upstream at https://github.com/bittorrent/libutp/issues so that it can be fixed in the right place. I'd prefer to not shear too far away from the upstream code.

comment:2 Changed 10 years ago by naddy

Well, the problem results from the interaction of third-party code and transmission's own transmission.h. libutp doesn't even use autoconf, so referring to HAVE_STDBOOL_H won't fly with the libutp people. If you don't want to touch the third-party libutp code, you'll have to tweak transmission.h and tr_utp.c in some way.

comment:3 Changed 10 years ago by jordan

Upstream should be involved in this discussion. We can throw around ideas on which way to slice this issue, but you still need to report it upstream.

comment:4 Changed 10 years ago by blakawk

  • Cc blakawk@… added

This bug has been reported upstream but has not been yet pulled into libutp master branch. As the pull request is closed, i added a comment in order to have it either fixed another way or merged.

comment:5 Changed 10 years ago by TurboPunk

Exact same thing happens when trying to compile on gentoo linux.

comment:6 follow-up: Changed 10 years ago by jordan

TurboPunk?: using what version of Transmission?

comment:7 in reply to: ↑ 6 Changed 10 years ago by TurboPunk

Replying to jordan:

TurboPunk?: using what version of Transmission?

The latest 'unstable' version currently in portage: 2.41

comment:8 Changed 10 years ago by cfpp2p

Exact same thing happens when trying to compile on NSLU2 UnSlung? 6.10 with a v2.42? , applied patch and compiled OK. A v2.42+ without patch compiles OK...

comment:9 Changed 10 years ago by x190

"A v2.42+ without patch compiles OK..." cfpp2p: Would you say this problem has been fixed then?

comment:10 Changed 10 years ago by cfpp2p

fixed for me since #4490 and no more: typedef uint8 bool

https://trac.transmissionbt.com/changeset/12954/trunk/third-party/libutp/utypes.h

Index: utypes.h
===================================================================
--- utypes.h	(revision 12953)
+++ utypes.h	(revision 12954)
@@ -35,8 +35,4 @@
 typedef const char * cstr;
 typedef char * str;
 
-#ifndef __cplusplus
-typedef uint8 bool;
-#endif
-
 #endif //__UTYPES_H__

comment:11 follow-up: Changed 9 years ago by jordan

cfpp2p, is this still an issue?

comment:12 in reply to: ↑ 11 Changed 9 years ago by cfpp2p

Replying to jordan:

cfpp2p, is this still an issue?

No longer an issue.

comment:13 Changed 9 years ago by jordan

  • Milestone None Set deleted
  • Resolution set to fixed
  • Status changed from new to closed

comment:14 Changed 8 years ago by vincent-

  • Cc vincent.riera@… added
  • Resolution fixed deleted
  • Status changed from closed to reopened

The problem was fixed when these 3 lines were removed from utypes.h:

-#ifndef cplusplus -typedef uint8 bool; -#endif

But now those 3 lines are present again and the compilation problem still existing.

As per suggestion of jordan, I'm reopening this bug:

[18:37] <@jordan> vicenteolivert: looks like livings124 just dropped in an updated version of libutp from upstream [18:37] <@jordan> vicenteolivert: please reopen #4528 and leave a comment about your build error, and I'll fix it

comment:15 Changed 8 years ago by jordan

  • Milestone set to 2.83

comment:16 Changed 7 years ago by jordan

  • Milestone changed from 2.83 to None Set
  • Resolution set to incomplete
  • Status changed from reopened to closed

No, I think my comment in IRC that was mentioned above in comment:14 must have been wrong. According to https://trac.transmissionbt.com/log/trunk/third-party/libutp/utypes.h the update that livings124 made was two years ago, which means that this would have been broken for about that long before FTBFS for Vincent.

I'm going to close this ticket for now as needinfo because the ticket needs more information about the build failure before the cause can be figured out.

Note: See TracTickets for help on using tickets.