@adamv At the time when I made this fix, I tried using just libstdcxx helper function. The compile phase would pass, but it would fail when linking. I believe that superenv tries to do the right thing and sets the environment correctly with the correct CXXFLAGS. 

Long winded explanation:

The root cause is not because Homebrew is broken, but because of how `clang` invokes the linker. It does not respect the `-stdlib=libstdc++` option when invoking the linker. I discovered this by trying install in homebrew's debug mode, and then using make's `-n` feature PLUS hacking the makefile to add `-v` to clang's invocation. `-n` will show you what make is doing, and `-v` on clang will show you what commands clang is running. You can see these args in an earlier comment I made in this pull request.

What this revealed is that the linker is still invoked with `-lc++`, which is the Apple/clang-specific implementation of the C++ standard library, not the posix-compliant stdc++. Adding `-Wl,-lstdc++` to clang's args causes clang to append `-lstdc++` to the arg list of `ld` (the linker), and then linking works OK.

I'm not sure if perhaps there is a better way to get this to happen, or what Apple's intention is by allowing you to change the stdlib implementation with the `-stdlib` clang option, but then not having that same standard library choice passed down to ld. That seems silly. 

Pure speculation: One hypothesis I have is that `clamav` is statically linking the C++ standard library at compile time to avoid potential threats that could harm clamav's effectiveness if the standard library shared .dylib is compromised. Since most software dynamically links the library, this oversight by clang would not noticeable. I don't know enough about how dynamic linking works to say that this is the case.