Building on OSX with setuptools 60.5.0 fails

[TimoWilken]

When building xrootd v5.4.0 on OSX 11.6.3 (Big Sur) with pip 21.3.1 and setuptools 60.5.0 installed, compiling xrootd's Python bindings fails with various errors related to code being compiled as C++98 instead of C++0x. It works fine with pip 21.3 and setuptools 58.2.0.

A full log of the build is here, with the build errors starting at line 4000. The problem is that bindings/python/src/PyXRootDCopyProcess.cc is compiled with the following command, which is missing the --std=c++0x option:

clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -fPIC -O2 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -arch x86_64 -I/Users/alibuild/Documents/sw/BUILD/e4239a59938fab56b67ecaa49f92c9eb05b7601d/XRootD/src -I/Users/alibuild/Documents/sw/BUILD/e4239a59938fab56b67ecaa49f92c9eb05b7601d/XRootD/build/src -I/usr/local/opt/python@3.9/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c /Users/alibuild/Documents/sw/BUILD/e4239a59938fab56b67ecaa49f92c9eb05b7601d/XRootD/bindings/python/src/PyXRootDCopyProcess.cc -o build/temp.macosx-11-x86_64-3.9/Users/alibuild/Documents/sw/BUILD/e4239a59938fab56b67ecaa49f92c9eb05b7601d/XRootD/bindings/python/src/PyXRootDCopyProcess.o -g

The following patch fixes this for me, but there may well be a better way of doing this:

diff --git a/bindings/python/setup.py.in b/bindings/python/setup.py.in
index cea13f3a9..05c139072 100644
--- a/bindings/python/setup.py.in
+++ b/bindings/python/setup.py.in
@@ -8,15 +8,15 @@ import subprocess
 # Remove the "-Wstrict-prototypes" compiler option, which isn't valid for C++.
 cfg_vars = sysconfig.get_config_vars()
 opt = cfg_vars["OPT"]
-cfg_vars["OPT"] = " ".join( flag for flag in opt.split() if flag not in ['-Wstrict-prototypes' ${CLANG_PROHIBITED} ] ) + " --std=c++0x"
+cfg_vars["OPT"] = " ".join( flag for flag in opt.split() if flag not in ['-Wstrict-prototypes' ${CLANG_PROHIBITED} ] )
 
 cflags = cfg_vars["CFLAGS"]
-cfg_vars["CFLAGS"] = " ".join( flag for flag in cflags.split() if flag not in ['-Wstrict-prototypes' ${CLANG_PROHIBITED} ] ) + " --std=c++0x"
+cfg_vars["CFLAGS"] = " ".join( flag for flag in cflags.split() if flag not in ['-Wstrict-prototypes' ${CLANG_PROHIBITED} ] )
 
 # pypy doesn't define PY_CFLAGS so skip it if it's missing
 if "PY_CFLAGS" in cfg_vars:
   py_cflags = cfg_vars["PY_CFLAGS"]
-  cfg_vars["PY_CFLAGS"] = " ".join( flag for flag in py_cflags.split() if flag not in ['-Wstrict-prototypes' ${CLANG_PROHIBITED} ] ) + " --std=c++0x"
+  cfg_vars["PY_CFLAGS"] = " ".join( flag for flag in py_cflags.split() if flag not in ['-Wstrict-prototypes' ${CLANG_PROHIBITED} ] )
 
 ccl=cfg_vars["CC"].split()
 ccl[0]="${CMAKE_C_COMPILER}"
@@ -81,7 +81,7 @@ setup( name             = 'xrootd',
                sources   = sources,
                depends   = depends,
                libraries = ['XrdCl', 'XrdUtils', 'dl'],
-               extra_compile_args = ['-g'],
+               extra_compile_args = ['--std=c++0x', '-g'],
                include_dirs = [xrdsrcincdir, xrdbinincdir],
                library_dirs = [xrdlibdir, xrdcllibdir]
                )

I also tried building #1586 instead, but I got the same errors, just during the pip install step later in the build.

[matthewfeickert]

When building xrootd v5.4.0 on OSX 11.6.3 (Big Sur) with pip 21.3.1 and setuptools 60.5.0 installed, compiling xrootd's Python bindings fails with various errors related to code being compiled as C++98 instead of C++0x. It works fine with pip 21.3 and setuptools 58.2.0.

@TimoWilken Have you tried building with setuptools releases between v58.2.0 and v60.5.0? It would be useful to know what version things actually break on so that you can also compare to the setuptools release notes: https://setuptools.pypa.io/en/stable/history.html

I also tried building #1586 instead, but I got the same errors, just during the pip install step later in the build.

PR #1586 isn't reflecting its true state at the moment (c.f. #1606 (comment)). It will get rebased soon and I can flag you there to see if it is still a problem.

Maybe you could open up a PR that adds a macos-latest job to the build GHA workflow? That would at least be a way to have a reproducible way to check builds in the future.

[matthewfeickert]

This has now been resolved in PR #1586.