Fixed

Ah, so you are extracting the objects from the lib and adding them individually, but it happens for every object?
If so, then there is probably another race here, since you are extracting all objects in the ar x operation, potentially overriding an object already extracted in a previous operation. this could be harmful.
But why are you extracting the objects and not just linking with the lib? Is that because it would require bigger modifications to the standard build process?

I wonder if stackman should simply be a single .obj or .o file instead of an .a. We could supply both, I suppose. Although, in the case of at least 32 bit windows, we need both .c code (the SEH wrapping code) and the .asm code, and they create different objects.... I wonder if it is possible to merge two object files into one....

Good point, you perfectly right. But now it should be OK.

But why are you extracting the objects and not just linking with the lib? Is that because it would require bigger modifications to the standard build process?

Yes, first I tried linking the lib, but I was not pleased with the result. The static libpython.a didn't contain the stackman object files and libstackman was listed in the output of python -m sysconfig like a system library.

Therefore changed the build process to simply extract all object files from libstackman. Now libpython.a contains the stackman object files and the existence of a libstackman.a is a hidden implementation detail of the build process. That's perfect.

I wonder if stackman should simply be a single .obj or .o file instead of an .a.

The archive is fine and more flexible.