Opened 8 years ago

Closed 7 years ago

#4490 closed Bug (fixed)

Transmission 2.40b1 fails to build: undefined references

Reported by: jbicha Owned by: jordan
Priority: Normal Milestone: 2.50
Component: Qt Client Version: 2.40
Severity: Major Keywords: backport-2.4x
Cc: costella@…, costela@…, alexandre.rossi@…

Description

Ubuntu 11.10 development. Build log attached. Several errors like this:

../libtransmission/libtransmission.a(net.o): In function `tr_netOpenPeerUTPSocket': /home/jeremy/devel/transmission/build-area/transmission-2.40b1/libtransmission/net.c:307: undefined reference to `UTP_Create' ../libtransmission/libtransmission.a(peer-io.o): In function `tr_peerIoNew': /home/jeremy/devel/transmission/build-area/transmission-2.40b1/libtransmission/peer-io.c:625: undefined reference to `UTP_SetSockopt'

Attachments (2)

buildlog.tar.gz (11.8 KB) - added by jbicha 8 years ago.
buildlog
tr-4490.patch (1.9 KB) - added by niol 8 years ago.
idea to fix the bug generating qt/config.pri.in from autoconf

Download all attachments as: .zip

Change History (15)

Changed 8 years ago by jbicha

buildlog

comment:1 Changed 8 years ago by jordan

  • Component changed from Transmission to Qt Client
  • Owner set to jordan

comment:2 Changed 8 years ago by jordan

jbicha, thanks for reporting this.

As a short-term workaround, you can build the qt client by runing qmake /after/ building all the other directories with autogen/configure/make.

What's happening here is that Transmission's qmake's rules only link against third-party/libutp/libutp.a if it was built before qmake is run. In your build log, the steps are running this way:

  1. configure and qmake are run before anything gets built. (So qmake thinks libutp is being omitted.)
  2. everything gets built (including a libtransmission dependency on libutp).
  3. in the final step of the build, transmission-qt's Makefile tries to link everything without libutp.

comment:3 Changed 8 years ago by jordan

  • Cc costella@… added
  • Milestone 2.40 deleted

comment:4 Changed 8 years ago by jordan

Okay. Looking at this build log a little further, it looks like this behavior is coming from a downstream Debian build script for Transmission. If the Debian people agree, I think this issue can be solved by changing that script s.t. it defers invoking qmake until just before the qt client is built (that is, after libtransmission, daemon, etc. have been built.)

cc'ing Leo to give him a heads-up.

comment:5 Changed 8 years ago by jordan

  • Resolution set to invalid
  • Status changed from new to closed

Since this is an issue with the Debian build script, I've submitted a downstream ticket at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642538

comment:6 Changed 8 years ago by costela

  • Cc costela@… added
  • Resolution invalid deleted
  • Status changed from closed to reopened

Please take a look at the patch suggested here: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=check_libutp_with_makefile.patch;att=1;bug=642538

As I wrote in the debian bug, I'm ok with fixing this on debian's side, but it seems a bit cleaner to make the configure step for the qt client depend only on the configure step for transmission as a whole, as opposed to depending on the *build* step. Let me know what you guys think and if possibe please test the small patch on non-debian systems to be sure there are no unforseen side-effects.

Thanks!

comment:7 Changed 8 years ago by jordan

  • Keywords backport-2.4x added
  • Milestone set to 2.50
  • Resolution set to fixed
  • Status changed from reopened to closed
  • Version changed from 2.33+ to 2.40

Fixed in r12954.

This also required adding AM_COND_IF to configure.ac; we'd been sloppy before and generated Makefile in third-party/libutp/ whether using libutp or not... :)

Unfortunately, 2.40 is already out. I've committed this to trunk, and will backport to the 2.4x branch if/when the dev team decides to make another 2.4x release.

comment:8 Changed 8 years ago by jordan

  • Resolution fixed deleted
  • Status changed from closed to reopened

Using AM_COND_IF in this way breaks make distclean because that rule uses on dist_dirs, which includes third-party/libutp/ whether we build libutp or not. When distclean reaches a directory without a makefile, it fails with an error.

I've reverted the use of AM_COND_IF in r12962, which means that third-party/libutp/Makefile will be generated whether we build libutp or not. This fixes make distclean but means that the exists(Makefile) test added added to qt/qtr.pro in r12954 won't work as expected.

Leo, do you have any other suggestions on this?

comment:9 Changed 8 years ago by costela

Sorry Jordan, I've been kinda swamped with other things and didn't manage to take a decent look at this. I do wanna do it eventually though, so please keep this bug open a few more weeks until I get around to it! I'm sure there's an (somewhat) elegant solution to this.

Thanks!

comment:10 Changed 8 years ago by niol

  • Cc alexandre.rossi@… added

What about the following :

--- qt/qtr.pro  (révision 13099)
+++ qt/qtr.pro  (copie de travail)
@@ -19,7 +19,7 @@
 INCLUDEPATH = $${EVENT_TOP}/include $${INCLUDEPATH}
 INCLUDEPATH += $${TRANSMISSION_TOP}
 LIBS += $${TRANSMISSION_TOP}/libtransmission/libtransmission.a
-exists( $${TRANSMISSION_TOP}/third-party/libutp/Makefile ) {
+system( grep \"^$${LITERAL_HASH}define WITH_UTP 1$\" $${TRANSMISSION_TOP}/config.log > /dev/null ) {
     LIBS += $${TRANSMISSION_TOP}/third-party/libutp/libutp.a
 }
 LIBS += $${TRANSMISSION_TOP}/third-party/dht/libdht.a

comment:11 Changed 8 years ago by jordan

Wouldn't that just move the bug to the Windows build?

Changed 8 years ago by niol

idea to fix the bug generating qt/config.pri.in from autoconf

comment:12 Changed 8 years ago by niol

Sorry, did not know Transmission was building on Windows.

And what about the attached patch?

comment:13 Changed 7 years ago by jordan

  • Resolution set to fixed
  • Status changed from reopened to closed

This is a great idea.

Adding upnp, natpmp to the config.pri.in template too.

Fixed r13200.

Note: See TracTickets for help on using tickets.