Python解释器嵌入段错误跟进问题：argc始终为0

咱们来一步步拆解你遇到的argc始终为0的异常，结合你编译嵌入Python程序的场景，主要从这几个方向入手：

1. Python初始化对argc的隐式修改 #

当你调用Py_Initialize()初始化Python解释器时，它会自动解析命令行参数，甚至会修改argc的值——比如移除掉Python相关的启动参数。如果你的代码是在Python初始化之后才去读取argc，那拿到的可能就是被修改后的值了。

解决办法：

• 在调用Py_Initialize()之前，先把argc的原始值保存到一个临时变量里，后续使用这个保存的值；
• 改用更可控的Py_InitializeFromArgs()来初始化，手动指定哪些参数需要被Python解析，避免它修改你的argc。

2. 动态库编译的特殊性（-shared选项） #

看你的编译命令用了-shared，这会生成动态链接库（.so文件），而不是可执行程序。动态库本身是没有自己的argc/argv的，这些参数完全由加载它的主程序传递。如果主程序没有正确把argc和argv传给你的库函数，或者你在库的入口逻辑里没有正确接收这些参数，就会出现argc为0的情况。

解决办法：

• 如果你本来就是要写动态库：确保你导出的核心函数接收argc和argv作为参数，比如定义一个像void my_lib_init(int argc, char** argv)的函数，让主程序调用时传入它自己的argc和argv；
• 如果你其实想编译可执行程序：把-shared换成-o your_program_name，同时在编译命令末尾加上Python库的链接选项（比如-lpython3.5m），生成可执行文件而非动态库。

3. 编译命令的不完整或冲突 #

你的编译命令里-L/usr/lib/p...没写完，要确保链接到了正确的Python库路径。另外，虽然-DNDEBUG和-g3这类选项不会直接导致argc异常，但完整的编译命令应该包含Python库的链接。这里给你一个修正后的可执行程序编译命令示例：

gcc -fno-diagnostics-color -Wall -Wno-unused-function \
-I. -g3 -I/usr/include/python3.5m \
-Wno-unused-result -Wsign-compare \
-fstack-protector-strong -Wformat -Werror=format-security \
-g -fwrapv -O3 -Wstrict-prototypes \
-L/usr/lib/python3.5/config-3.5m-x86_64-linux-gnu -lpython3.5m \
your_source_file.c -o your_executable

4. 代码中argc的获取逻辑错误 #

最后检查你的代码逻辑：

• 如果是可执行程序的main函数，直接用int main(int argc, char* argv[])的参数是没问题的；
• 如果是动态库的入口（比如_init函数），不能直接获取argc，必须由加载它的主程序主动传递参数给你。

快速验证最小示例 #

你可以先写一个极简的测试程序，快速定位问题根源：

#include <Python.h>
#include <stdio.h>

int main(int argc, char *argv[]) {
    printf("初始化Python前的argc: %d\n", argc);
    Py_Initialize();
    printf("初始化Python后的argc: %d\n", argc);
    Py_Finalize();
    return 0;
}

用上面修正后的编译命令编译运行，看看两次打印的argc值变化，就能快速判断是Python初始化的问题，还是其他环节的问题。

内容的提问来源于stack exchange，提问作者wvxvw