树莓派项目用dh_virtualenv打包.deb时Gfortran编译NumPy失败

我之前也碰到过一模一样的情况——直接在虚拟环境里装NumPy、SciPy完全正常，但用dh_virtualenv打包就触发编译失败。核心原因通常是打包过程的构建环境和你直接安装的环境不一致：dh_virtualenv默认可能会启用pip的构建隔离，或者系统层面缺少编译依赖导致的。下面是几个亲测有效的解决方法：

1. 补全系统级编译依赖 #

虽然你直接安装时没问题，但打包时dh_virtualenv可能在一个更“干净”的上下文里构建，所以先把树莓派系统上的编译依赖补全：

sudo apt-get install gfortran gcc g++ python3-dev libopenblas-dev liblapack-dev

这些是NumPy、SciPy编译必须的底层库和工具，装完之后能解决大部分编译找不到依赖的问题。

2. 让dh_virtualenv禁用pip构建隔离 #

pip的--no-build-isolation参数会让它直接使用系统已安装的编译工具和依赖，而不是创建隔离的临时环境重新下载编译依赖。你需要在debian/rules文件里添加这个配置：

override_dh_virtualenv:
	dh_virtualenv --extra-pip-arg="--no-build-isolation"

这样dh_virtualenv调用pip安装依赖时，就会复用系统里的Gfortran和其他库，避免重新编译时找不到工具。

3. 预编译wheel包跳过编译步骤 #

如果上面的方法还是不行，或者你想彻底避免打包时的漫长编译，可以先在树莓派上预编译好NumPy、SciPy和scikit-learn的wheel包：

# 直接指定虚拟环境的pip生成wheel包
myvenv/bin/pip wheel numpy scipy scikit-learn -w ./wheels/

编译完成后，在debian/rules里配置dh_virtualenv从本地wheel安装：

override_dh_virtualenv:
	dh_virtualenv --extra-pip-arg="--find-links=./wheels/" --extra-pip-arg="--no-index"

这样打包时pip会直接用本地的wheel包安装，完全跳过编译环节，既快又不会出编译错误。

4. 检查构建环境的环境变量 #

有时候问题出在打包时的环境变量缺失，比如Gfortran的路径没在PATH里。可以在debian/rules开头添加环境变量配置：

export PATH := /usr/bin:$(PATH)
export LD_LIBRARY_PATH := /usr/lib/arm-linux-gnueabihf/:$(LD_LIBRARY_PATH)

确保编译工具和系统库的路径能被正确找到。

按上面的步骤来，应该就能解决打包时Gfortran编译NumPy的问题了。

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