libtorrent-rasterbar @1.2.2 fails to build on mavericks

[tehcog (tehcog)]

please see attached log file.

--->  Computing dependencies for libtorrent-rasterbar
--->  Fetching archive for libtorrent-rasterbar
--->  Attempting to fetch libtorrent-rasterbar-1.2.2_0+python27.darwin_13.x86_64.tbz2 from https://packages.macports.org/libtorrent-rasterbar
--->  Attempting to fetch libtorrent-rasterbar-1.2.2_0+python27.darwin_13.x86_64.tbz2 from http://ywg.ca.packages.macports.org/mirror/macports/packages/libtorrent-rasterbar
--->  Attempting to fetch libtorrent-rasterbar-1.2.2_0+python27.darwin_13.x86_64.tbz2 from http://aus.us.packages.macports.org/macports/packages/libtorrent-rasterbar
--->  Fetching distfiles for libtorrent-rasterbar
--->  Verifying checksums for libtorrent-rasterbar
--->  Extracting libtorrent-rasterbar
--->  Applying patches to libtorrent-rasterbar
--->  Configuring libtorrent-rasterbar
--->  Building libtorrent-rasterbar
Error: Failed to build libtorrent-rasterbar: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_net_libtorrent-rasterbar/libtorrent-rasterbar/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

[tehcog (tehcog)]

main.log

[ryandesign (Ryan Carsten Schmidt)]

The first error I see in the log is:

error: unknown type name 'constexpr'

Brief searching leads me to understand this is a C++11 feature, so the fix may be as simple as adding -std=c++11 to configure.cxxflags (or probably better to use the new compiler.cxx_standard option introduced in MacPorts 2.6.0).

[ryandesign (Ryan Carsten Schmidt)]

Trying to use it myself in another port, I'm realizing that apparently setting compiler.*_standard only helps you select a compatible compiler. It doesn't add the -std flag for you. You still have to do that separately.

[ryandesign (Ryan Carsten Schmidt)]

In fact the port does use compiler.cxx_standard 2011. The attached log shows it using MacPorts clang++ 8 to build some earlier parts. But the build system then fails to use the requested compiler when "building 'libtorrent' extension", going back to using /usr/bin/clang, which of course fails. The compiler selection needs to be propagated to all parts of the build

[dbevans (David B. Evans)]

Fixed by updating to version 1.2.3 and explicitly adding -std=c++11 to configure.cxxflags. As @ryandesign has found out, compiler.cxx_standard doesn't do this for you, so the port failed with compilers that don't default to C++11. This includes Apple clang on 10.11 and earlier.

See ​https://github.com/macports/macports-ports/commit/8e9cef33d3ea55bb1250adbb3237c18b6a75f0f8

[kencu (Ken)]

We talked about whether base should set that standard as part of setting the cxx_standard, and decided it should not do so, based on conflicts with other similar standards such as gnu++11 etc.