Homebrew-core: Last v8 bottle breaks linking on macOS by installing conflicting /usr/local/lib/libc++.dylib

[fxdupont]

I upgraded my v8 on macOS mojave (10.14.3) to the last available version
(brew cat v8 and brew upgrade logs say 7.3.492.23).

Building C++ applications start to fail. Trivial hello world:

#include <iostream>
int main() {
    std::cout << "hellp world" << std::endl;
    return 1;
}

does not compile: `g++ hello.cc" fails saying it can't find a lot of symbols:

Undefined symbols for architecture x86_64:
...
  "std::__1::cout", referenced from:
      _main in x-fbc1be.o
...

The problem is they are defined in /usr/lib/libc++.dylib which is hidden by:

% ls -l /usr/local/lib/libc++.dylib
lrwxr-xr-x  1 dupont  40 Mar 20 00:31 /usr/local/lib/libc++.dylib -> ../Cellar/v8/7.3.492.23/lib/libc++.dylib

I found two simple ways to fix this:

• add -L/usr/lib to g++ commands to help ld to find the right libc++ library
• uninstall v8 (temporary until the v8 formula is fixed)

[SMillerDev]

This is the "intended" behaviour of v8, it won't work without it. See for example the comment Arch Linux has here: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=v8#n179

[fxcoudert]

@SMillerDev that we allow v8 to install libraries that shadow system libraries in /usr/local/lib is, however, not following Homebrew's rule, is it?

[fxdupont]

If the choice is between breaking macOS or breaking v8 I prefer the second. And BTW even I believe the culprit is macOS / Xcode it is very unlikely to get it fixed one day...

IMHO v8 libraries should be installed into /usr/local/lib/v8 (and includes into /usr/local/include/v8 to answer to the Arch Linux reference). Note #36551 is related to this issue too.

[MikeMcQuaid]

@fxcoudert Agreed. If it _has_ to install those, it _has_ to be keg-only I think.

[fxcoudert]

Possibly it could install everything into libexec and symlink its executable into bin.