Graphviz doesn't build on MacOS with the latest libc++
[I'm the libc++ maintainer]
I was trying to build Graphviz using the latest version of libc++ (the C++ Standard Library shipped with the Clang compiler, and used on Apple platforms), and I noticed the following error:
In file included from <graphviz>/blocks.cpp:22: In file included from <graphviz>/blocks.h:32: In file included from <toolchain>/usr/bin/include/c++/v1/set:427: In file included from <toolchain>/usr/bin/include/c++/v1/__tree:17: In file included from <toolchain>/usr/bin/include/c++/v1/algorithm:644: In file included from <toolchain>/usr/bin/include/c++/v1/functional:512: In file included from <graphviz>/Block.h:26: In file included from <toolchain>/usr/bin/include/c++/v1/vector:274: <toolchain>/usr/include/c++/v1/__bit_reference:172:38: error: no member named 'min' in namespace 'std::__1'
The issue is that we
#include <Block.h> from , however Graphviz contains a block.h header (which is the same as Block.h on a case insensitive FS), and they collide. This triggers some circular dependency issue in libc++, which causes the build to fail. The root cause of the issue is that by including
<Block.h> in libc++, we're potentially conflicting with a user-provided
<Block.h> header. It would be better if
<Block.h> were somehow namespaced, so that we know for sure we're not including a user provided header, however that's not the reality we live in.
I suggest fixing Graphviz in one of two ways:
- Rename your
block.hheader to something else, or
- Avoid adding
<graphviz>/lib/vpscto the include paths of the compiler. Instead, add
<graphviz>/liband then include
<vpsc/block.h>from your code. This will effectively namespace the block.h header from your side, making sure that we don't find it when we include
I acknowledge this is an annoying issue and I wish we had a better way of solving it from our side in libc++, however I can't think of a good solution from our side.