企业官网建设流程全解析

如何为 Linux-musl（Alpine）编译 PaddlePaddle wheel 供 TEE 环境使用？

【免费下载链接】PaddlePArallel Distributed Deep LEarning: Machine Learning Framework from Industrial Practice （『飞桨』核心框架，深度学习&机器学习高性能单机、分布式训练和跨平台部署）项目地址: https://gitcode.com/GitHub_Trending/pa/Paddle

如果你的目标是让 PaddlePaddle 跑在基于 musl libc 的 Linux 环境（如 Alpine），进而部署到 libOS 类 SGX TEE（文档明确列出的对象是商用产品 Scone 和社区维护的 Occlum）中，就需要一份针对 linux-musl 编译的 wheel 包，而不是常规的 glibc wheel。Paddle 仓库在 paddle/scripts/musl_build/ 目录内置了完整的构建脚本，本文按 README 给出的流程，讲清楚如何在这套脚本上产出一个.whl文件，以及如何验证构建结果。

整套构建依赖宿主机上的 Docker：脚本通过docker build构建一个以python:${PYTHON_VERSION}-alpine3.11为基础镜像的编译环境（见 Dockerfile），再在容器内完成 Paddle 源码的编译。README 说明当前支持 Scone 与 Occlum 两类 TEE，对开源 TEE Graphene 的支持当时仍在推进中，这一点在引入 TEE 选型时值得留意。

构建目录里的各脚本做什么

先明确 musl_build 目录下文件的职责，后文会用到它们：

主路径：自动构建 wheel

以下命令来自 README 的 Build Automatically 一节，均在 Paddle 源码根目录的build/目录内执行，../paddle/scripts/...是相对于该 build 目录的路径。

第 1 步，克隆 Paddle 源码并进入 build 目录（clone 地址可替换为你实际使用的镜像源）：

git clone https://gitcode.com/GitHub_Trending/pa/Paddle.git cd ./Paddle mkdir -p build && cd build

第 2 步，构建编译镜像。网络较慢时可通过HTTP_PROXY/HTTPS_PROXY环境变量设置代理（README 示例如下，两个 export 均为可选）：

# setup proxy address, when the speed of internet is not good. # export HTTP_PROXY='http://127.0.0.1:8080' # export HTTPS_PROXY='https://127.0.0.1:8080' # invoke build script ../paddle/scripts/musl_build/build_docker.sh

第 3 步，在镜像中编译 Paddle。build_paddle.sh接收的参数会原样透传给make，例如-j8：

../paddle/scripts/musl_build/build_paddle.sh -j8

自动模式下的容器以--network host运行，并把源码根目录、./output、ccache 与缓存目录挂载进容器；编译结束后 build_paddle.sh 会自动执行find "$OUTPUT_DIR" -type f列出产物。

结果验证：wheel 保存在相对于工作目录的./output目录，README 给出的检查命令是：

ls ./output/*.whl

看到./output/下出现.whl文件即表示本次构建产出成功。

可选：带单元测试的构建

如果需要更强的正确性验证，可用WITH_TEST=1触发测试链路（build_inside.sh）：容器内会安装单测依赖、pip install刚产出的 wheel，然后执行ctest --output-on-failure；ctest 的具体参数可以通过CTEST_*环境变量透传。注意这会把构建时间显著拉长，且依赖网络安装测试依赖：

WITH_TEST=1 ../paddle/scripts/musl_build/build_paddle.sh -j8

可选：手动模式进入容器编译

需要逐步控制编译命令时，用BUILD_MAN=1进入容器交互 shell 而不是直接跑完编译（此模式不会挂--rm，容器会保留，需要时自行停止或删除）：

BUILD_MAN=1 ../paddle/scripts/musl_build/build_paddle.sh

进入容器后（源码挂载在/paddle，工作目录为/root），按 README 的 Build Manually 一节依次执行：

mkdir build && cd build # install python requirement pip install -r /paddle/python/requirements.txt # configure project with cmake cmake -DWITH_MUSL=ON -DWITH_CRYPTO=OFF -DWITH_MKL=OFF -DWITH_GPU=OFF /paddle # the argument -j8 is optional to accelerate compiling. make -j8

编译产物 wheel 位于构建目录下的python/dist/（自动模式的 build_inside.sh 即用find python/dist/ -type f -name '*.whl'定位它并拷入/output）。

常用环境变量与副作用说明

两个脚本支持的环境变量在 README 的 Scripts 一节有完整清单，与日常执行相关的主要是这些：

限制与文档间差异

• musl 构建的 cmake 选项在 build_inside.sh 中固定为-DWITH_MUSL=ON -DWITH_CRYPTO=OFF -DWITH_MKL=OFF -DWITH_GPU=OFF，即这条路径产出的 wheel 不含 GPU 与 MKL 支持，这也是该目录 README 手动构建一节给出的同样参数。
• 构建镜像的 Alpine 版本存在文档间不一致：README 描述为 alpine 3.10，而 Dockerfile 实际基于alpine3.11，以 Dockerfile 为准时建议以当前仓库代码为准核对。
• PYTHON_VERSION的默认值同样两处不一致：README 写 default=3.8，build_docker.sh 与 Dockerfile 的默认值均为 3.7。需要固定版本时建议显式设置PYTHON_VERSION，不要依赖默认值。
• 文档只覆盖了"如何产出 musl wheel"，并未说明 wheel 在 Scone/Occlum 内部的具体部署与运行方式，这部分需参考对应 TEE 项目的文档，本文不展开。

继续深入

• 构建产物与挂载逻辑：build_paddle.sh、config.sh
• 容器内编译细节（cmake 参数、wheel 收集、测试流程）：build_inside.sh
• 构建环境定义：Dockerfile、package.txt
• 原始使用说明：paddle/scripts/musl_build/README.md

【免费下载链接】PaddlePArallel Distributed Deep LEarning: Machine Learning Framework from Industrial Practice （『飞桨』核心框架，深度学习&机器学习高性能单机、分布式训练和跨平台部署）项目地址: https://gitcode.com/GitHub_Trending/pa/Paddle