error: invalid argument -std=gnu++<snip> not allowed with C

[AndrewAmmerlaan]

setup.py seems to apply C++ flags to C code, leading to compile failures:
dev-python libsass-python-0.22.0 20221114-220613.log

Originally reported here: https://bugs.gentoo.org/881339

[asottile]

Gentoo is elevating the warning to an error, that's on them

[thesamesam]

We're definitely not. It's Clang that's bailing out.

Note that in this case, it's not just saying "unknown argument, treating as an error" (which Clang can do and there's a way to suppress it), it's actually saying "-std is valid for C but I have no idea what value you just told me to use" (because C++ happens to have a -std too). In this case, it's not an unknown option causing the failure, but garbage ("c++0x", wrt a C compiler) passed into an argument which happens to be valid in C (-std).

But it's always invalid to pass CXXFLAGS to a C compiler anyway. For example, -Werror=odr is completely valid for C++, and means nothing for C. So, even if we were, it'd be something to fix (if minor).

Could you elaborate on what you mean please?

[asottile]

it's building fine for us on clang so it's (as last time and as usual with Gentoo) something they're doing

[thesamesam]

The flags setup.py passes to CC are always C++ only. There's no variable used to just pass to CC.

On a fresh clone of libsass-python:

$ python setup.py build
/usr/lib/python3.11/site-packages/setuptools/config/setupcfg.py:508: SetuptoolsDeprecationWarning: The license_file parameter is deprecated, use license_files instead.
  warnings.warn(msg, warning_class)
running build
running build_py
running build_ext
building '_sass' extension
x86_64-pc-linux-gnu-gcc -Wsign-compare -DNDEBUG -fPIC -DPy_LIMITED_API -I./libsass/include -I/usr/include/python3.11 -c _sass.c -o build/temp.linux-x86_64-cpython-311/_sass.o -fPIC -std=gnu++0x -Wall -Wno-parentheses -Werror=switch -DLIBSASS_VERSION=\"3.6.5\"
cc1: warning: command-line option ‘-std=gnu++11’ is valid for C++/ObjC++ but not for C
x86_64-pc-linux-gnu-gcc -Wsign-compare -DNDEBUG -fPIC -DPy_LIMITED_API -I./libsass/include -I/usr/include/python3.11 -c libsass/src/ast.cpp -o build/temp.linux-x86_64-cpython-311/libsass/src/ast.o -fPIC -std=gnu++0x -Wall -Wno-parentheses -Werror=switch -DLIBSASS_VERSION=\"3.6.5\"

/tmp/libsass-python $ CC=clang python setup.py build
/usr/lib/python3.11/site-packages/setuptools/config/setupcfg.py:508: SetuptoolsDeprecationWarning: The license_file parameter is deprecated, use license_files instead.
  warnings.warn(msg, warning_class)
running build
running build_py
running build_ext
building '_sass' extension
clang -Wsign-compare -DNDEBUG -fPIC -DPy_LIMITED_API -I./libsass/include -I/usr/include/python3.11 -c _sass.c -o build/temp.linux-x86_64-cpython-311/_sass.o -fPIC -std=gnu++0x -Wall -Wno-parentheses -Werror=switch -DLIBSASS_VERSION=\"3.6.5\"
error: invalid argument '-std=gnu++0x' not allowed with 'C'
error: command '/usr/lib/llvm/15/bin/clang' failed with exit code 1

It's just that GCC doesn't bail out on this, but Clang does. setup.py doesn't treat CC and CXX differently and hence always passes C++ specific flags.

Could you show me where e.g. your CI builds with Clang so I can try spot what the difference is? I looked at Azure but I couldn't spot the right part. Thanks!

[asottile]

the macos builds run on clang for example

[mgorny]

The MacOS builds use platform.system() == 'Darwin' code path that applies different flags than Linux builds. Also, clang's behavior varies across platforms.

[mazunki]

Would be cool if developers actually listened to maintainers instead of blaming them for reporting errors :)

[asottile]

would be cool if package maintainers actually maintained instead of throwing things over the fence -- our builds are green

[mazunki]

Passing checks is only sufficient if checks encompass the whole scope. If you don't care about clang on Linux, just say that instead.

[AndrewAmmerlaan]

would be cool if package maintainers actually maintained instead of throwing things over the fence -- our builds are green

What is this supposed to mean? The package maintainers are maintaining it, in fact the problem has already been fixed in the Gentoo repository. This Issue is an attempt to bring the fix to the rest of Linux, hardly "throwing things over the fence", I would appreciate a more constructive attitude from your side.

[asottile]

I don't see a patch?

[AndrewAmmerlaan]

I don't see a patch?

You can find the sed command we use to fix this issue in the bug report I linked in my first post. But since you asked so nicely I went ahead and put it in a patch form for you:

diff --git a/setup.py b/setup.py
index a3719a9..95ccf1f 100644
--- a/setup.py
+++ b/setup.py
@@ -15,10 +15,10 @@ from setuptools import setup
 
 MACOS_FLAG = ['-mmacosx-version-min=10.7']
 FLAGS_POSIX = [
-    '-fPIC', '-std=gnu++0x', '-Wall', '-Wno-parentheses', '-Werror=switch',
+    '-fPIC',  '-Wall', '-Wno-parentheses', '-Werror=switch',
 ]
 FLAGS_CLANG = ['-c', '-O3'] + FLAGS_POSIX + ['-stdlib=libc++']
-LFLAGS_POSIX = ['-fPIC',  '-lstdc++']
+LFLAGS_POSIX = ['-fPIC',  ]
 LFLAGS_CLANG = ['-fPIC', '-stdlib=libc++']
 
 sources = ['_sass.c']