On Nov 12, 2013, at 9:27 PM, Mark Moll <mm...@macports.org> wrote: > > On Nov 12, 2013, at 5:28 PM, Lawrence Velázquez <lar...@macports.org> wrote: > >> On Nov 12, 2013, at 4:43 PM, mm...@macports.org wrote: >> >>> Revision: 113226 >>> https://trac.macports.org/changeset/113226 >>> Author: mm...@macports.org >>> Date: 2013-11-12 13:43:58 -0800 (Tue, 12 Nov 2013) >>> Log Message: >>> ----------- >>> py-graph-tool: apparently <tuple> is not part of libstdc++ for clang, so >>> force libc++ >>> >>> Modified Paths: >>> -------------- >>> trunk/dports/python/py-graph-tool/Portfile >>> >>> Modified: trunk/dports/python/py-graph-tool/Portfile >>> =================================================================== >>> --- trunk/dports/python/py-graph-tool/Portfile 2013-11-12 21:01:11 UTC >>> (rev 113225) >>> +++ trunk/dports/python/py-graph-tool/Portfile 2013-11-12 21:43:58 UTC >>> (rev 113226) >>> @@ -68,6 +68,9 @@ >>> configure.ldflags-append -L${prefix}/lib >>> configure.args-append --with-boost=${prefix} >>> --exec-prefix=${python.prefix} >>> configure.cxxflags-append -std=c++11 >>> + if {[string match *clang* ${configure.compiler}]} { >>> + configure.cxxflags-append -stdlib=libc++ >>> + } >>> # Clang uses the old libstc++ from gcc 4.2 before OS X 10.9. Boost doesn't >>> # include some of the tr1 headers in libstdc++ and defines its own tr1 >>> # classes. This causes conflicts with sparsehash which insists on using >> >> What happens when this is built on a 10.6 system, which doesn't have libc++? > > Right now, it doesn’t seem to build. This particular port depends on other > ports that use some advanced C++ (boost and cgal) and you can’t just enable > C++11 for one port and not its dependencies, as I found out. I suspect I > can’t remove the “-std=c++11” flag and use gcc48 for example, since this > would use libstdc++ and boost would be using libc++. The RTTI used by > Boost.Python, for example, would cause problems. I can’t think of a good > solution for this. For now, the port might be Mavericks only.
Actually, one solution would be to keep the version clamped at the latest official release (2.2.26) for 10.8 and older, since the C++11-compatible code can’t be made to work easily (at least, I don’t see how). On 10.9, none of the official releases work and only the C++11 branch of the git repo of graph-tool works. Assuming this will be merged in default, all future versions would only be available on 10.9. -- Mark Moll _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
