net-p2p/rtorrent does not build on freebsd 9 thru 9.3 and possibly 10.1 and it appears there has not been a package available for a while on http://portsmon.freebsd.org/portoverview.py?category=net-p2p&portname=rtorrent On my 9.3-RELEASE-p5 system, for ports I am using gcc from base, and gcc4.8 from ports for a few special ports. I found that this port will build if forced to use gcc48 I patched the ports Makefile like so: ====== --- /usr/ports/net-p2p/rtorrent/Makefile.orig +++ /usr/ports/net-p2p/rtorrent/Makefile @@ -14,7 +14,7 @@ LIB_DEPENDS= libcurl.so:${PORTSDIR}/ftp/curl GNU_CONFIGURE= yes -USES= pkgconfig +USES= pkgconfig compiler:c++11-lib LDFLAGS+= -pthread CONFIGURE_ARGS= --disable-debug @@ -33,7 +33,7 @@ .endif # Workaround to build on >= 10.x -.if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1000000 +.if ${OPSYS} == FreeBSD && ${OSVERSION} >= 900000 CXXFLAGS+= -std=c++11 EXTRA_PATCHES+= ${FILESDIR}/extra-clang .endif ======== doh. I missed changing the comment in my patch. If anyone else can try this patch and see if it helps them with rtorrent that would be great. Anyone with more USES=compiler:foo could see if another option would let clang compile this too. Thanks Craig
Hi, I have been unable to reproduce the problem you report. The package is building fine on 9.3. Also both the portsmon page you cite and the build cluster show the package as successfully building (pkgs are build on the oldest supported release, so packages for 9.3 are build on 9.1. Every FreeBSD major release strives to maintain binary compatibility with previous point releases). You can look at a successful build log from the cluster here: http://beefy1.isc.freebsd.org/bulk/latest-per-pkg/rtorrent/0.9.4_1/91i386-default.log Do you have a failure log for the problem you report? Thanks!
Created attachment 149968 [details] rtorrent fails to build with base gcc on 9
Created attachment 149969 [details] rtorrent builds for me with gcc48 and a patch to the makefile
I have added the logs from a successful and the failed builds I agree with your explanation of the portsmon page. I didn't realize that the blank spots for the releng versions in the middle were expected. thanks for looking at this.
(In reply to Craig Wiesen from comment #4) > I have added the logs from a successful and the failed builds > > I agree with your explanation of the portsmon page. I didn't realize that > the blank spots for the releng versions in the middle were expected. > > thanks for looking at this. uname -a FreeBSD desktop.home.org 9.3-RELEASE-p5 FreeBSD 9.3-RELEASE-p5 #0 r274128: Tue Nov 4 23:40:39 CST 2014 root@desktop.home.org:/usr/obj/usr/src/sys/SANDYBRIDGE amd64 # gcc -v Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] gcc48 -v Using built-in specs. COLLECT_GCC=gcc48 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc48/gcc/x86_64-portbld-freebsd9.3/4.8.3/lto-wrapper Target: x86_64-portbld-freebsd9.3 Configured with: ./../gcc-4.8.3/configure --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc48 --libexecdir=/usr/local/libexec/gcc48 --program-suffix=48 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc48/include/c++/ --with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar --enable-languages=c,c++,objc,fortran,java --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc48 --build=x86_64-portbld-freebsd9.3 Thread model: posix gcc version 4.8.3 (FreeBSD Ports Collection)
(In reply to Craig Wiesen from comment #2) > Created attachment 149968 [details] > rtorrent fails to build with base gcc on 9 Have you tried rebuilding the net-p2p/libtorrent port? The error message reports missing symbols from that library, not in the port being build.
ok, I think i may have narrowed down my problem more. As Guido points out this was initially a mismatch between the symbols of libtorrent and rtorrent failing the linking step. I am forcing gcc as my favorite compiler. So in my case libtorrent/Makefile has: USES= compiler:c++11 and in the rtorrent/Makefile has no such USES= compiler: so when built in gcc the namespaces between libtorrent and rtorrent didn't match during the link step. Where as observed on beefy2 (the amd64 builds) they are both being built with clang which appears to imply USES= compiler:c++11 so the lack of USES= compiler:c++11 in libtorrent/Makefile does not matter and the namespaces match. So if I just append compiler:c++11 to the rtorrent/Makefile USES= pkgconfig compiler:c++11 It should do the correct thing for both clang and gcc. Does that make sense?
(In reply to Craig Wiesen from comment #7) > ok, I think i may have narrowed down my problem more. > > As Guido points out this was initially a mismatch between the symbols of > libtorrent and rtorrent failing the linking step. > > > I am forcing gcc as my favorite compiler. > > > So in my case libtorrent/Makefile has: > USES= compiler:c++11 > > and in the rtorrent/Makefile has no such > USES= compiler: > > so when built in gcc the namespaces between libtorrent and rtorrent didn't > match during the link step. > > > > Where as observed on beefy2 (the amd64 builds) they are both being built > with clang which appears to imply > USES= compiler:c++11 > > so the lack of > USES= compiler:c++11 > in libtorrent/Makefile does not matter and the namespaces match. > > > > So if I just append compiler:c++11 > to the rtorrent/Makefile > USES= pkgconfig compiler:c++11 > > It should do the correct thing for both clang and gcc. > > > Does that make sense? Yes it does. clang and gcc use two different and incompatible implementations of libc++, for the standard C++ classes. So, while code compiled with gcc and clang is compatible, when the mixed code references two different implementations like this it does not compile or, worse, fails at runtime. I think, since libtorrent has USES=compiler and so honors the FAVORITE_COMPILER variable, that rtorrent should have it too. I'll test a little and commit a fix. Thanks for your report and help in the analysis!
A commit references this bug: Author: madpilot Date: Thu Dec 4 14:57:47 UTC 2014 New revision: 373913 URL: https://svnweb.freebsd.org/changeset/ports/373913 Log: Add USES=compiler to rtorrent port. Various ports it depends on have the same USES and so honour the FAVORITE_COMPILER, and doing the dsame here avoids build problems when using FAVORITE_COMPILER=gcc. PR: 195397 Submitted by: Craig Wiesen <ctyz1999+bugzilla at gmail.com> Changes: head/net-p2p/rtorrent/Makefile
Fix committed. Thanks!