rtorrent and libtorrent fail to build except with --cc=gcc-4.9

[Habbie]

gist-logs from 'brew install libtorrent': https://gist.github.com/Habbie/39a3d4e057da2957894644febfa16142
gist-logs from brew install rtorrent: https://gist.github.com/Habbie/df0cd0299e70753bf0add69a6a5cc996

brew install --cc=gcc-4.9 libtorrent (and same for rtorrent) work for me.

Not sure how to debug this further. Haven't managed to ask other users to try this. Let me know what I can do to debug this further!

[ilovezfs]

The original issue is from 2013 Homebrew/legacy-homebrew#24132

Should we just go back to clang and maybe it's fixed by now?

[Habbie]

Good point, I can test that. Do I just remove the fails_with :clang block to switch it back to clang?

[ilovezfs]

Yes. Both of them compiled and the tests passed just now but only extended usage will tell the tale based on how the original issue describes what went down.

[Habbie]

How did you compile? I now get

Last 15 lines from /Users/peter/Library/Logs/Homebrew/rtorrent/03.make:
../../rak/priority_queue_default.h:40:10: fatal error: 'tr1/functional' file not found
#include <tr1/functional>
         ^
1 error generated.

and again I'm happy to debug but if it already works for you I'm curious to hear what you did.

[Habbie]

To be clear, rtorrent is failing that way, libtorrent did build and install after removing fails_with :clang.

[ilovezfs]

@Habbie you have to also put back in the ENV.libstdcxx if ENV.compiler == :clang that is commented out.

[Habbie]

Oh that makes sense to get new C++ stuff.

[Habbie]

It crashed for me:

Caught Segmentation fault, dumping stack:
0   rtorrent                            0x000000010a0bfacb _Z8do_panici + 233
1   libsystem_platform.dylib            0x00007fff90165f1a _sigtramp + 26
2   ???                                 0x0000000000000002 0x0 + 2
3   libtorrent.19.dylib                 0x000000010a2e855b _ZN7torrent16HandshakeManager14receive_failedEPNS_9HandshakeEii + 81
4   libtorrent.19.dylib                 0x000000010a2e693a _ZN7torrent9Handshake10event_readEv + 1360
5   libtorrent.19.dylib                 0x000000010a298842 _ZN7torrent10PollKQueue7performEv + 238
6   libtorrent.19.dylib                 0x000000010a2bd64f _ZN7torrent11thread_base10event_loopEPS0_ + 415
7   rtorrent                            0x000000010a0bf4f3 main + 13415
8   libdyld.dylib                       0x00007fff8acff5c9 start + 1
9   ???                                 0x0000000000000003 0x0 + 3
Abort trap: 6

so apparently we can't go clang on both. Maybe on one, not sure. My inclination is to submit a PR that would switch them to 4.9 without manual user intervention, do you have hints on how to put that in a formula?

[ilovezfs]

This probably belongs in the boneyard.

[mistydemeo]

Does it still segfault if we change the optimization level? Has the segfault been reported upstream? I know the C++11 compilation failure was, but I don't know if the segfault ever was.

[mistydemeo]

Hm, no, the C++11 compilation failure is still totally there - never mind.

[mistydemeo]

The C++11 branch was merged into master two years ago, but has yet to make it into a stable release: rakshasa/libtorrent@77a0f35

[dunn]

@Habbie both compile for me with GCC 5.3.0

[ilovezfs]

@mistydemeo Not really.
rakshasa/rtorrent#350
rakshasa/rtorrent#240
rakshasa/rtorrent#170

rakshasa/rtorrent#44
rakshasa/rtorrent#32
rakshasa/rtorrent#14

[Habbie]

Just as a datapoint, a clang libtorrent + 4.9 rtorrent also crashes.

[Habbie]

@dunn does brew have a flag for that today?

[dunn]

If you have gcc-5 available, it should use it automatically, since it's marked as failing with Clang. But --cc=gcc-5 should work too.

[ilovezfs]

Other than possibly boneyarding this formula, I don't think there's an issue here beyond the usual things-that-don't-build-with-clang-don't-really-belong-in-core problem.

[MikeMcQuaid]

I don't think there's an issue here beyond the usual things-that-don't-build-with-clang-don't-really-belong-in-core problem.

It's on my TODO list to kill these.