-
Notifications
You must be signed in to change notification settings - Fork 541
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pip_install fails with error: command '/usr/bin/gcc' failed with exit code 1
#681
Comments
I believe the issue lies with the hermetic interpreters which are now used, apparently by default. The installed interpreters libs don't seem have the correct header files present. |
@davians12 I can't repro this exact issue because I develop on macos. Can you put together a repro of the WORKSPACE which create this issue. In particular are you using a custom python interpreter toolchain target or the built in hermetic toolchains? |
@hrfuller Yep this is totally expected with the python-build-standalone intepreter.
It's failed to find a wheel for |
So this issue is basically the linux equivalent of #646 but in the integration test I added to #679 I can't repro this failure with linux. To me that implies that the interpreter setup here is slightly different. In particular this include path |
I am seeing the same thing, using a custom Python toolchain and the I've tried looking through the issues on those packages for relevant changes, but not found anything obvious yet. The simple test would be to update these packages one-by-one or just bulk upgrade all of these to their latest version to see if there was a bug that's been resolved. This works (commit prior to fe30f15): http_archive(
name = "rules_python",
sha256 = "00360543865915c7492371b631e6824e1bd6976c88062242a65da0e6b18618c0",
strip_prefix = "rules_python-0f189979467de61cb0512cc0a133d2122e041e90",
url = "https://github.com/bazelbuild/rules_python/archive/0f189979467de61cb0512cc0a133d2122e041e90.zip",
) This fails: http_archive(
name = "rules_python",
sha256 = "18a8d97f706d768169f93e251d02eea6f8e1810bd90c2fe78cfdf036aa1772ef",
strip_prefix = "rules_python-fe30f1561e3afef59e3f8be6339c88444100de25",
url = "https://github.com/bazelbuild/rules_python/archive/fe30f1561e3afef59e3f8be6339c88444100de25.zip",
) @davians12: Do you see the same behaviour when you use the above rules_python versions? I'll try to extract a repro repo too. |
So, this has been a rabbit hole into Python builds. The repo I have that reproduces this is similar in setup to the demo code you have here in this repo, where Python is pulled and built in patch commands. Given the The package update that breaks the build is setuptools between v60.1.1 and v60.2.0. Looking at the diff, there are changes to the way Python build config files are detected, which appears to have a knock-on effect in how the include paths are generated in build_ext when building the wheel. The section of interest appears to be in how distutils checks if a Python executable is part of a 'non-installed' build and changes behaviour if so. The critical piece here is the final Python binary is symlinked back into the source tree, which makes distutils think we are in an uninstalled Python build due to the presence of the source files alongside the binary. So, as far as I can tell, this is not a bug in rules_python nor any of the upstream Python packages, but rather a latent problem in mangling Python build directories that hasn't mattered until an unrelated cleanup in distutils exposed it. The fix for users with this build setup is to ensure that the final binary/symlink that is given to your toolchain/pip_install/pip_parse is not positioned alongside the source files, to prevent distutils getting confused. I have done this by separating the source and build dirs in the |
Coincidentally running into the same issue. The setuptools upgrade was introduced here: #661 |
I'm currently winding back |
Are you running with the new built-in toolchains or a custom Python toolchain? Rolling back setuptools may be a short-term solution, but that only hides the issue and we should be able to upgrade it freely in the future (particularly as new Python releases come out that could start to have issues with a very old setuptools version). In this particular case for this issue: there's nothing that rules_python can fix (besides maybe updating the demo code I linked), as it's my local custom toolchain layout that was breaking distutils. It just so happens that a fair number of us have adopted and adapted that original demo code, so are seeing similar bugs. |
My issue is now resolved after upgrading I no longer believe I was seeing the same issue, so I think we still need to see a repro from the original poster to be certain (although I do think @aaliddell has the best explanation so far). |
Agreed the @aaliddell bisect makes sense to me. |
@davians12 Can you confirm whether @aaliddell fix solves your issue? |
A useful closure here could be to update the example python build toolchain here to fix the symlink being inside the source tree. |
For me this was fixed on MacOS by version 0.12.0. From the release notes, I'm guessing fixed by #809 |
This issue was automatically closed because it went 30 days without a reply since it was labeled "Can Close?" |
🐞 bug report
Affected Rule
The issue is caused by the rule: pip_installIs this a regression?
Yes, the previous version in which this bug was not present was: Not a regressionDescription
pip_install fails for only one requirement `tree-sitter` from `requirements.txt`🔥 Exception or Error
🌍 Your Environment
Operating System:
Output of
bazel version
:Rules_python version:
Anything else relevant?
The bazel setup used to build and run, not sure what changed.
The text was updated successfully, but these errors were encountered: