Bug 195397

Comment 1 Guido Falsi 2014-11-28 10:05:29 UTC

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)

Comment 6 Guido Falsi 2014-11-30 16:27:19 UTC

(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?

Comment 8 Guido Falsi 2014-12-03 11:43:58 UTC

(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!

Comment 9 commit-hook 2014-12-04 14:58:04 UTC

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

Comment 10 Guido Falsi 2014-12-04 14:58:11 UTC

Fix committed.

Thanks!