download the latest installer from the MSYS2 page
In the terminal, install the MinGW-w64 toolchain by running the following command:
pacman -S --needed base-devel mingw-w64-ucrt-x86_64-toolchain
Add the path to your MinGW-w64 bin folder to the Windows PATH environment
C:\msys64\ucrt64\bin
References
https://code.visualstudio.com/docs/cpp/config-mingw
Create the C function:
First, create a file named add.c with the following content:
// add.c
#include <stdio.h>
int add(int a, int b) {
return a + b;
}
Compile the C function:
Next, you need to compile the C code into a shared library. If you’re on Linux or macOS, you can use gcc:
gcc -shared -o libadd.so -fPIC add.c
On Windows, you might use gcc from MinGW:
gcc -shared -o add.dll -Wl,--out-implib,libadd.a add.c
Call the C function from Python:
Create a Python script named call_add.py with the following content:
import ctypes
# Load the shared library into ctypes
if __name__ == "__main__":
lib = ctypes.CDLL('./libadd.so') # Use 'add.dll' on Windows
# Define the argument and return types of the C function
lib.add.argtypes = [ctypes.c_int, ctypes.c_int]
lib.add.restype = ctypes.c_int
# Call the C function
result = lib.add(3, 5)
print(f'The result of adding 3 and 5 is: {result}')
-fpic
Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts (the dynamic loader is not part of GCC; it is part of the operating system). If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that -fpic does not work; in that case, recompile with -fPIC instead. (These maximums are 8k on the SPARC, 28k on AArch64 and 32k on the m68k and RS/6000. The x86 has no such limit.)
Position-independent code requires special support, and therefore works only on certain machines. For the x86, GCC supports PIC for System V but not for the Sun 386i. Code generated for the IBM RS/6000 is always position-independent.
When this flag is set, the macros __pic__ and __PIC__ are defined to 1.
from Wikipedia :
In computing, position-independent code (PIC) or position-independent executable (PIE) is a body of machine code that, being placed somewhere in the primary memory, executes properly regardless of its absolute address. PIC is commonly used for shared libraries, so that the same library code can be loaded in a location in each program address space where it will not overlap any other uses of memory (for example, other shared libraries)
Example :
swig -python hello.i gcc -fpic -c hellomodule.c hello_wrap.c -I/usr/include/python3.4/ gcc -shared hellomodule.o hello_wrap.o -o _hello.so
References :
https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html https://en.wikipedia.org/wiki/Position-independent_code
-shared
Produce a shared object which can then be linked with other objects to form an executable. Not all systems support this option. For predictable results, you must also specify the same set of options used for compilation (-fpic, -fPIC, or model suboptions) when you specify this linker option.
Example :
gcc -fpic -c hellomodule.c hello_wrap.c -I/usr/include/python3.4/ gcc -shared hellomodule.o hello_wrap.o -o _hello.so
Reference :
-o file
Place output in file file. This applies to whatever sort of output is being produced, whether it be an executable file, an object file, an assembler file or preprocessed C code.
If -o is not specified, the default is to put an executable file in a.out, the object file for source.suffix in source.o, its assembler file in source.s, a precompiled header file in source.suffix.gch, and all preprocessed C source on standard output.
Example :
gcc -shared hellomodule.o hello_wrap.o -o _hello.so
References :