building python3Packages.protobuf3_2 on OS X fails due to string include

[robx]

Issue description

Building the python 3 protobuf package fails for me on macOS.

$ nix-build '<nixpkgs>' -A python3Packages.protobuf3_2
...
clang -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I../src -I/nix/store/nkmdx27mxqq4mz9qvnbd8v754y290ndf-python3-3.6.1/include/python3.6m -c google/protobuf/pyext/descriptor.cc -o build/temp.macosx-10.6-x86_64-3.6/google/protobuf/pyext/descriptor.o -Wno-write-strings -Wno-invalid-offsetof -Wno-sign-compare -Wno-shorten-64-to-32 -std=c++11
clang-4.0: warning: argument unused during compilation: '-fno-strict-overflow' [-Wunused-command-line-argument]
google/protobuf/pyext/descriptor.cc:35:10: fatal error: 'string' file not found
#include <string>
         ^~~~~~~~
1 error generated.
error: command 'clang' failed with exit status 1
builder for ‘/nix/store/2z36gcrnmi2bz1a3s3nppc8imp11ppgj-python3.6-protobuf-3.2.0.drv’ failed with exit code 1
error: build of ‘/nix/store/2z36gcrnmi2bz1a3s3nppc8imp11ppgj-python3.6-protobuf-3.2.0.drv’ failed

Digging in (by launching nix-shell -A python3Packages.protobuf3_2), the cause seems to be that python setup.py build_ext --cpp_implementation calls CC=clang instead of CXX=clang++. The clang call above fails, but the same call works after replacing clang by clang++. Similarly, CC=$CXX python setup.py build_ext --cpp_implementation works fine.

That in turn matters because of

if [[ "$isCpp" = 1 ]]; then
    if [[ "$cppInclude" = 1 ]]; then
        NIX_CFLAGS_COMPILE="$NIX_CFLAGS_COMPILE ${NIX_CXXSTDLIB_COMPILE-}"
    fi
    NIX_CFLAGS_LINK="$NIX_CFLAGS_LINK $NIX_CXXSTDLIB_LINK"
fi

in the clang/clang++ wrappers, because the system include path NIX_CXXSTDLIB_COMPILE is missing in the clang case.

Technical details

• System: mac OS 10.12.5
• Nix version: nix-env (Nix) 1.11.8
• Nixpkgs version: "17.09pre108299.ec9a23332f"
• Sandboxing enabled: grep: /etc/nix/nix.conf: No such file or directory :)

When digging in, I used a checkout of nixpkgs with hash 63e9d1c, but it seems to make no difference.

[robx]

#16450 seems related.

[FRidh]

@knedlsepp uses Python on Darwin and might help here.

[robx]

I've had a look at the python setup tools: The relevant line is (rather: appears to be, I haven't tested this) https://github.com/python/cpython/blob/master/Lib/distutils/unixccompiler.py#L58:

    executables = {'preprocessor' : None,
                   'compiler'     : ["cc"],
                   'compiler_so'  : ["cc"],
                   'compiler_cxx' : ["cc"], // <- here
                   'linker_so'    : ["cc", "-shared"],
                   'linker_exe'   : ["cc"],
                   'archiver'     : ["ar", "-cr"],
                   'ranlib'       : None,
                  }

which causes C++ source files to be compile with $CC. Not sure whether this is the right or wrong thing to do...

I see two reasonable ways to fix this bug, in a more principled way than #26606:

1. fix python distutils to compile C++ files using $CXX
2. fix nixpkg clang-wrapper/bin/cc to treat cc like c++ with respect to $cppInclude and friends

If 1. is the right thing to do, it might still be nice to work around the bug in another way for now.

[knedlsepp]

I've also been bitten by this problem once:
#18729
The core problem is that setuptools pretty much ignores the difference between CC and CXX. This however is not a problem on a standard mac xcode installation, as both clang++ and clang link the C++ standard library there.
However our nix-clang does not link against the C++ standard library (and probably should not) and that's why you will encounter this problem every once in a while when dealing with darwin and c++ python extensions.
I'm not an expert on the darwin-stdenv, so I wouldn't know how to fix this in a way that does not require hacking our ways around that problem.
To hack around this problem you simply have to grep the pythonPackages for libcxx. There are a few packages that use a workaround that involves adding libcxx to the C-compile flags:
See e.g. here:

nixpkgs/pkgs/development/python-modules/matplotlib/default.nix

Line 32 in 6b999f3

NIX_CFLAGS_COMPILE = stdenv.lib.optionalString stdenv.isDarwin "-I${libcxx}/include/c++/v1";

[FRidh]

The core problem is that setuptools pretty much ignores the difference between CC and CXX. This however is not a problem on a standard mac xcode installation, as both clang++ and clang link the C++ standard library there.
However our nix-clang does not link against the C++ standard library (and probably should not) and that's why you will encounter this problem every once in a while when dealing with darwin and c++ python extensions.

@LnL7 @copumpkin any clue how to solve this issue?

[knedlsepp]

The problem does not seem all-too widespread, but there are a few instances:

Search results for: "${libcxx}/include/c++/v1"

python

numba
matplotlib
pandas

haskell

llvm-general

R

R

other

qt-4.8
juicipp
cctools
xcode
irods
maloader

[copumpkin]

Any reason we can't just change https://github.com/python/cpython/blob/master/Lib/distutils/unixccompiler.py#L58 to use c++? Seems like it would work on Linux just fine, and fix a bunch of other stuff.

[LnL7]

I knew this was an issue in general (#18729), but assumed the problem was something more complicated.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/tensorflow-on-20-09-mac/11931/5

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-shells-and-python-packages-with-c-extensions/26326/1