[113226] trunk/dports/python/py-graph-tool/Portfile

[Joshua Root]

On 2013-11-13 14:27 , Mark Moll wrote:
> 
> On Nov 12, 2013, at 5:28 PM, Lawrence Velázquez <larryv at macports.org> wrote:
> 
>> On Nov 12, 2013, at 4:43 PM, mmoll at macports.org wrote:
>>
>>> Revision: 113226
>>>         https://trac.macports.org/changeset/113226
>>> Author:   mmoll at 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.

Yeah, I believe the eventual goal is to switch everything to libc++ on
10.6+ for this reason. The only way you can get away with using a
different C++ runtime is if you don't link to and are not linked to by
anything else written in C++.

There is a libcxx port for the benefit of 10.6 BTW.

- Josh