Failed to build graphviz

[Ryan Schmidt]

On Feb 13, 2022, at 02:59, Rainer Müller wrote:
> 
> On 10/02/2022 13.12, Greg Bell wrote:
>> I'm trying to update yt-dlp (a youtube-dl fork with additional features and fixes)
>> 
>> and incurred this…
>> Error: Failed to build graphviz: command execution failed
>> 
>> I'm unsure how to interpret the log.
>> Log output attached in zipped folder.
> 
> The most relevant error message from the log is this one:
> 
> :info:build
> /opt/local/libexec/llvm-11/bin/../include/c++/v1/__bit_reference:172:38:
> error: no member named 'min' in namespace 'std::__1'
> 
> There is already a ticket which describes the same problem for graphviz:
> https://trac.macports.org/ticket/60962

That ticket and all of its duplicates were only experienced by users on macOS Catalina who had failed to update their command line tools to a Catalina-compatible version; therefore no further investigation was planned. Learning that Snow Leopard is now affected as well would be a significant new detail. Maybe it has been caused by MacPorts base recently switching to using a newer MacPorts clang on 10.6 and other older systems.

>> Running OS X 10.6.8 (my maximum OS for 2 GHz Intel Core 2 Duo)

Did you mean Core Duo? Core Duo and Core Solo systems are limited to 10.6.8 maximum, but Core 2 Duo system should be able to upgrade to at least 10.7.5.

> That is a very old system... I honestly do not know the state of
> libstdc++ vs. libc++ these days on legacy systems, but could it be some
> mismatch between the two C++ runtime libraries?

Graphviz built successfully on 10.6.8 last time we tried to do so on December 26; see the port health indicators:

https://ports.macports.org/port/graphviz/details/

In MacPorts, 10.6 and later use libc++, but since 10.6-10.8 don't default to libc++, some ports have bugs that cause them to fail to build on 10.6-10.8 due to stdlib mismatch (such as failing to supply the MacPorts-specified CXXFLAGS to the build system); in that case, these bugs should be fixed. I don't think that's the case here, because, grepping through Greg's log, every invocation of clang++ does indeed already have the required -stdlib=libc++ argument.