Properly attribute ntextapi symbols as extern

[georgthegreat]

Summary

• OS: Windows
• Bug fix: no
• Type: core

Description

At the time, an attempt to compile the binding with (on by default) clang-cl's `-fno-common leads to the following error:
psutil.lib(_psutil_common.c.py2.obj) : error LNK2005: _RtlNtStatusToDosErrorNoTeb already defined in psutil.lib(_psutil_windows.c.py2.obj).

(as to my knowledge, the best description of fcommon mechanics can be found in GCC's bugzilla.

This PR properly attributes functions as extern in every place except for the _psutil_common.c which is going to assign proper values to them.

[giampaolo]

I don't know what fcommon mechanic is. It looks like you're using some sort of non standard/default compile configuration. Also I'm not sure why you mention GCC. The only supported compiler on Windows is Visual Studio. (are you using VS?)

[georgthegreat]

-fcommon behavior is explained e. g. here. I believe this is a historical legacy related to Fortran COMMON keyword, but this does not actually matter:

This code is a variable definition, not variable declaration:

BOOL (WINAPI *_GetLogicalProcessorInformationEx) (
    LOGICAL_PROCESSOR_RELATIONSHIP relationship,
    PSYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX Buffer,
    PDWORD ReturnLength);

(hence this variable is defined in every compile unit the header is included into)

If MSVS is able to compile this, this is clearly a bug in MSVC's linker, as duplicate symbol error should be raised instead.

As for clang-cl support, many projects switched to clang on Windows. This list includes but not limited to Firefox and Chrome.

[giampaolo]

But are you using Visual Studio? This is Windows so I don't understand why you're mentioning gcc.

[georgthegreat]

We use both clang-cl and MSVS on Windows.
This PR is clang-cl specific though.

I did not make a research why MSVS is able to compile and link this.
But there is some problem indeed (the code should not link), thanks for pointing this out.

[giampaolo]

The only officially supported compiler is Visual Studio (same policy adopted by the cPython project). In the past I tried to keep mingw support alive, but it proved to be too difficult to maintain, and after some years I removed it. Since then we're basically VS only. Closing.