Closed
Description
Bug report
If make sharedinstall fails to install some Python extensions, the make target wrongly succeeds. For example, I'm seeing:
/usr/bin/install -c -m 755 Modules/array.cpython-312-x86_64-linux-gnu.so /usr/lib/python3.12/lib-dynload/array.cpython-312-x86_64-linux-gnu.so
/usr/bin/install: cannot create regular file '/var/tmp/portage/dev-lang/python-3.12.0_alpha3/image/usr/lib/python3.12/lib-dynload/array.cpython-312-x86_64-linux-gnu.so': No such file or directory
/usr/bin/install -c -m 755 Modules/_asyncio.cpython-312-x86_64-linux-gnu.so /usr/lib/python3.12/lib-dynload/_asyncio.cpython-312-x86_64-linux-gnu.so
/usr/bin/install: cannot create regular file '/var/tmp/portage/dev-lang/python-3.12.0_alpha3/image/usr/lib/python3.12/lib-dynload/_asyncio.cpython-312-x86_64-linux-gnu.so': No such file or directory
/usr/bin/install -c -m 755 Modules/_bisect.cpython-312-x86_64-linux-gnu.so /usr/lib/python3.12/lib-dynload/_bisect.cpython-312-x86_64-linux-gnu.so
[...]
Nevertheless, make install returns successfully in this case. This causes major problems for automated builds since they end up with broken Python installs when the make target should have failed.
I need to investigate why it's failing but that's a separate issue.
Complete build log (1.2M): dev-lang:python-3.12.0_alpha3:20221207-142002.log
The problem seems to be that the sharedinstall targets runs a single shell command and make doesn't check the exit status until its very end.
I suspect the same problem may apply to other install rules.
Your environment
- CPython versions tested on: 3.12.0a3
- Operating system and architecture: Gentoo Linux/amd64
Linked PRs
Metadata
Metadata
Assignees
Labels
The build process and cross-buildThe build process and cross-buildAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error