[BUG] CC="ccache gcc" stopped working for C++ builds since setuptools-60.0.0

[bjodah]

setuptools version

setuptools>=60.0.0

Python version

CPython 3.9

OS

Ubuntu 20.04 LTS

Additional environment information

Description

Running setup.py build_ext with CC set to "ccache gcc-11" causes this to happen when building a c++ extension module:

g++-11 gcc-11 -shared -Wl,-rpath=/opt/cpython-3.9-debug/lib -Wl,--disable-new-dtags -Wl,-rpath,/opt/sundials-5.7.0-noklu-nolapack-dbg/lib -L/opt/sundials-5.7.0-noklu-nolapack-dbg/lib -isystem /opt/sundials-5.7.0-noklu-nolapack-dbg/include build/temp.linux-x86_64-3.9-pydebug/pyodeint/_odeint.o -L/opt/cpython-3.9-debug/lib -o build/lib.linux-x86_64-3.9-pydebug/pyodeint/_odeint.cpython-39d-x86_64-linux-gnu.so
/usr/bin/ld: cannot find gcc-11: No such file or directory

Setting SETUPTOOLS_USE_DISTUTILS=stdlib yields the expected linkline:

g++-11 -pthread -shared -Wl,-rpath=/opt/cpython-3.9-debug/lib -Wl,--disable-new-dtags -Wl,-rpath,/opt/sundials-5.7.0-noklu-nolapack-dbg/lib -L/opt/sundials-5.7.0-noklu-nolapack-dbg/lib -isystem /opt/sundials-5.7
.0-noklu-nolapack-dbg/include build/temp.linux-x86_64-3.9-pydebug/pyodeint/_odeint.o -L/opt/cpython-3.9-debug/lib -o build/lib.linux-x86_64-3.9-pydebug/pyodeint/_odeint.cpython-39d-x86_64-linux-gnu.so
copying build/lib.linux-x86_64-3.9-pydebug/pyodeint/_odeint.cpython-39d-x86_64-linux-gnu.so -> pyodeint

The compile comands look alright though:
ccache gcc-11 -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -g -Og -Wall -Og -g3 -Og -g3 -isystem /opt/sundials-5.7.0-noklu-nolapack-dbg/include -fPIC -DANYODE_NO_LAPACK=1 -DNDEBUG -DBOOST_UB LAS_TYPE_CHECK=0 -Ipyodeint/include -I/opt/cpython-3.9-debug/lib/python3.9/site-packages/numpy/core/include -Iexternal/anyode/include -I/opt/cpython-3.9-debug/include/python3.9d -c pyodeint/_odeint.cpp -o build/ temp.linux-x86_64-3.9-pydebug/pyodeint/_odeint.o -std=c++20

Perhaps the space between ccache and g++ is unaccounted for in setuptools (own?) distutils?

Expected behavior

How to Reproduce

Output

[bmerry]

I can reproduce this with CC="ccache gcc" pip install --no-binary spead2 spead2==3.7.0, although it has a sizable compile time so one can probably find simpler packages to exhibit the same behaviour.

[jaraco]

It's quite possible that something evolved in the distutils implementation after it was adopted from the stdlib. Setuptools' own copy of distutils has been around since v50 (IIRC), but was opt-in with SETUPTOOLS_USE_DISTUTILS=local. Maybe it would make sense to bisect those versions to see which version of setuptools introduced the change. But before we could do that, we'd need a good minimal reproducer.

I also notice that 'numpy' is implicated here. It's a known issue that numpy patches distutils (stdlib only) (#2372), so it could be the expected behavior only works with those patches.

Can you determine if the issue is unique to numpy or if simple extensions are affected as well?

[bjodah]

@jaraco , thanks, I created a reproducer:

https://github.com/bjodah/reproducer-setuptools-ccache-gh3130

My findings are as follows:
When setting SETUPTOOLS_USE_DISTUTILS=local, then:

• Using (latest) NumPy (1.22.2):
  • 58.0.4 is OK
  • 58.1.0 is bad
• Using no numpy:
  • 58.0.4 is OK
  • 58.1.0 is bad

Hope this is of any help.

[jaraco]

That's a huge help. You've narrowed the problem to these changes. From there, I was quickly able to find f182b5e, which is almost certainly implicated in the regression. I'll transfer this issue to distutils.

[jaraco]

That commit was added in #54.

[jaraco]

@isuruf Would you be willing to work out a solution that captures this regression and restores the prior expectation?

[isuruf]

Sure. I'll look into it

[isuruf]

It's not #54, it's #53.

[isuruf]

See #117

[jaraco]

It's not pypa/distutils#54, it's pypa/distutils#53.

Thanks for the PR @isuruf. I looked at the PR and these two previous PRs, and it's not at all obvious to me why #53 was the cause of the reported issue. Can you describe how the changes in #53 led to the failure?

[isuruf]

Before #53, linker_so command was,

gcc -pthread -shared <rest>

and after #53, setting export CC="ccache gcc" would make linker_so to be,

ccache gcc -pthread -shared <rest>

When the link language was C++, distutils would look at the first word and replace it. So before #53,
it became,

g++ -pthread -shared <rest>

and after #53 with export CC="ccache gcc" it became

g++ gcc -pthread -shared <rest>

Does that make sense? I can describe in more detail if you want.