Wrong absolute path format in the fallback PREFIX path

[robtor-de]

Bug report

When building for windows with mingw-w64-ucrt and embedding the interpreter into another application I encounter the issue that when running unittests the base library search path mechanism fails. This issue itself does not matter because I already found the root of this problem:

The interpreter dumps it's system configuration where sys.PREFIX is set to sth. like: \\C\\path\\to\\buildtree\\libs
The path itself is correct but is inproperly formatted. In comparison sys.EXECUTABLE looks like C:\path\to\python3.11.exe, the way it should.

After digging into the mechanism how python determines this path I found out that after all other search mechanism See doc fails it will take a kind of fallback path hardcoded into the executable. Unfortunately exactly this hardcoded path has this faulty msys style path with double backslashes, so it will look for a network share on windows.

Then I found out that in the configure step a variable called @prefix_b2h@ is created but never used. This variable holds the same path as @prefix@ but properly formatted for the host system. When looking at getpath.c you can see that if it never gets overwritten this path then comes per define into the executable here:

cpython-mingw/Modules/getpath.c

Line 930 in 9d73243

!decode_to_dict(dict, "PREFIX", PREFIX) ||

cpython-mingw/Makefile.pre.in

Line 1298 in 9d73243

-DPREFIX='"$(prefix)"' \

So my suggestion is to use the prefix_b2h path for the compilation of getpath.c:

From 7ba71602bb2ef2aff61b1e0499de0fd3d3e65eae Mon Sep 17 00:00:00 2001
From: Robin Dietzel <robtor2000@web.de>
Date: Mon, 17 Jun 2024 08:55:57 +0200
Subject: [PATCH] Use b2h for getpath

---
 Makefile.pre.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile.pre.in b/Makefile.pre.in
index c480a89ce6..3175df2072 100644
--- a/Makefile.pre.in
+++ b/Makefile.pre.in
@@ -1295,8 +1295,8 @@ Modules/getbuildinfo.o: $(PARSER_OBJS) \

 Modules/getpath.o: $(srcdir)/Modules/getpath.c Python/frozen_modules/getpath.h Makefile $(PYTHON_HEADERS)
        $(CC) -c $(PY_CORE_CFLAGS) -DPYTHONPATH='"$(PYTHONPATH)"' \
-               -DPREFIX='"$(prefix)"' \
-               -DEXEC_PREFIX='"$(exec_prefix)"' \
+               -DPREFIX='"$(prefix_b2h)"' \
+               -DEXEC_PREFIX='"$(prefix_b2h)"' \
                -DVERSION='"$(VERSION)"' \
                -DVPATH='"$(VPATH)"' \
                -DPLATLIBDIR='"$(PLATLIBDIR)"' \
--
2.39.2

Probably this issue wasn't noticable yet because if you properly deploy the installation (not like in my unittests) the libraries will be found and the prefix gets overwritten with the correct path. But the faulty fallback path would still remain hardcoded within the executable.

Your environment

• CPython versions tested on: 3.11.8
• Operating system and architecture: Windows11 amd64