Many places check for the string 'GCC' in sys.version to identify a
'posix' build.
Remove anchor from regex for extracting version number from -v/--version
output. The presence of a git commit hash in LLD's ld -v output was
confusing it. This doesn't seem entirely save, but solves the immediate
problem.
set CC to clang on clang prefix, to fix LTO/PGO
Remove mktime workaround now that mingw-w64 exports that symbol.
Not sure why it is there (git history doesn't help).
It results in Python passing it to setuptools when building extensions
which results in extensions never having debug symbols even if built with "--debug".
Just remove it.
In case of cygpty we want to fake a tty and at the same time make
Python behave as if it was attached to a console.
This improves two thing in that regard:
* Update the is_cygpty patch to cover more isatty() checks (likely
they were added since the patch was created)
* Default the stdio encoding to the console output encoding by default.
This is only in effect if stdout isn't redirected (then is uses the ANSI code page)
and no real console is used (then it forces utf-8). Python never considers the
case were isatty() and no console, so we have to add this.
This makes printing unicode work again in MSYS2 bash.
Turns out Python uses the basename of the calling executable to
decide which launcher in the venv it uses to call pip with.
This means we have to copy all launchers we ship.
Use the non versioned launchers as src so the rewrite logic in venv
copies the venvlauncher variants.
Fixes#7227
The venv code for the uninstalled case depends on various hacks only
present in the Windows code paths, so instead of using the unix ones
patch the windows ones.
We now create a venvlauncher.exe in the build dir which gets copied
to the venv package during install, and when run uninstalled copies
it to the created venvs. This is mroe in line with what the msvc build
does.
We aren't currently compiling the venvlauncher as part of python with
gcc. Previous patches in PR #5625 removed the venvlauncher redirector
by skipping "nt" platform portions in the venv module.
Although the previous patches worked to fix venv, it left us with key
venvlauncher files missing that were expected to be present in Windows.
In issue #7014, tox and other tools that depend on virtualenv were
unable to run. For example, there was issues with no such file or
directory errors:
'mingw64/lib/python3.8/venv/scripts/nt/python.exe'
This fixes these issues by removing some of the previous patches in venv
and copying python.exe and pythonw.exe to the locations where the
venvlauncher redirect files are expected. A future solution may be to
try to compile venvlauncher using gcc.
* remove commented out stuff
* remove mtime changes, handled by "make rebuild-x" in newer Python
* remove patch for changing the exe names so it happens for all tools in one place
