登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  php教程

PHP 8.6 最低构建依赖变化会影响哪些源码编译脚本

来源:17golang原创

时间:2026-09-09 01:49:24 380浏览 收藏

如果你的 CI 是从 php-src Git 仓库拉代码,再执行 buildconf 生成 configure,PHP 8.6 的最低构建依赖变化会直接影响这条脚本:Autoconf 应升级到 2.71,同时编译器要能稳定使用 C11。若使用 PHP 官方发布压缩包,里面已经带有预生成的 configure,通常不需要为了这次变化额外安装 Autoconf。

先按源码来源分流:Git 构建检查 Autoconf 2.71 和 C11,再运行 buildconf;发布压缩包直接从 ./configure 开始。不要把源码生成工具、编译器能力和数据库运行时能力混成一项检查。
要点速览
  • RFC 已接受的构建侧变化是 Autoconf 2.71,以便可靠要求 C11。
  • 只从 Git 源码生成配置脚本的流水线需要改;发布压缩包的入口不变。
  • MySQL/MariaDB 与 persistent connection 的变化属于另一条运行时回归线。

PHP 8.6 先区分 Git 源码和发布压缩包

PHP 官方 RFC 把 Autoconf 2.71 的原因说得很具体:旧的 2.68 不认识 C11,可能让特性探测给出不明显的构建失败。PHP 手册也把 C11 列为 PHP 8.4 起的编译器要求。这里真正容易误改的是入口。

从 Git 源码构建时,buildconf 会参与生成配置脚本,所以 CI 镜像需要准备 Autoconf、Bison、re2c 和 C 编译器。下载发布压缩包时,configure 已由发布流程生成,脚本可以直接执行配置和编译。两种路径都需要 C11 编译器,但只有前者需要把 Autoconf 版本作为硬门槛。

PHP 8.6 Git 源码、buildconf、Autoconf 2.71、预生成 configure 与 C11 编译器的构建边界关系图
图1:PHP 8.6 源码构建的关键边界:Git 源码需要生成 configure,发布压缩包直接使用已生成脚本。

把编译依赖拆成可提前失败的检查

不要等 buildconf 深处才看到难懂的宏错误。把版本检查放在构建脚本开头,失败信息应告诉维护者“哪条路径、哪个工具、最低版本是什么”。下面这段只作为 Git 源码构建的前置门禁:

#!/usr/bin/env bash
set -eu

# Git 源码需要用 Autoconf 生成 configure,先拒绝旧版本。
autoconf_version="$(autoconf --version | awk 'NR == 1 {print $NF}')"
if [ "$(printf '%s\n' "$autoconf_version" 2.71 | sort -V | head -n 1)" != "2.71" ]; then
  echo "需要 Autoconf 2.71 或更高版本,当前为 $autoconf_version" >&2
  exit 1
fi

# C11 是编译器能力检查,不要只检查 gcc 或 clang 的名字。
printf '%s\n' "$(cc --version | sed -n '1p')"

# 只有仓库源码需要生成配置脚本。
if [ -x ./buildconf ]; then
  ./buildconf
fi
./configure --disable-all --enable-cli
make -j"$(getconf _NPROCESSORS_ONLN 2>/dev/null || echo 2)"

这个门禁不替代完整依赖安装。启用 GD、国际化或数据库扩展时,还要检查对应开发库;但这些是功能选项的依赖,不应被误报成 Autoconf 版本问题。

CI 和本地迁移怎么改才不误伤 tarball

建议把流水线分成两个明确 job。Git job 固定使用新鲜的构建镜像,在生成配置脚本后继续 ./configuremake 和测试;tarball job 不调用 buildconf,只验证发布包能按既定选项配置。这样既能覆盖开发者构建路径,也不会把 Autoconf 强行变成运行时镜像依赖。

迁移时优先检查脚本里的三个信号:是否执行了 git clone 或 checkout、是否调用 ./buildconf、是否把 autoconf --version 写进构建日志。若脚本只解压发行包并直接调用 ./configure,重点应放在 C 编译器和扩展开发库,而不是盲目新增生成工具。

把编译依赖与数据库运行时依赖分开回归

同一份 PHP 8.6 RFC 还讨论了 MySQL 5.7.3 和 MariaDB 10.2.4 提供的 COM_RESET_CONNECTION,目的是让 PDO 和 mysqlnd 在复用持久连接时能重置连接状态。这不是“源码编译失败”的另一种写法,而是编译成功后的运行时能力检查。

检查面关注对象失败时先看什么
源码生成Autoconf 2.71、buildconf构建镜像与源码来源
编译能力C11、扩展开发库编译器与 configure 输出
连接运行时mysqlnd、PDO、COM_RESET_CONNECTION数据库版本与持久连接配置
PHP 8.6 编译工具链与 mysqlnd PDO 持久连接运行时能力的分组关系图
图2:迁移回归应分开看编译工具链和数据库连接能力,避免把两类失败误判成同一个依赖问题。

因此,CI 最少保留两类结果:源码构建是否通过,以及启用持久连接时数据库状态是否能被安全重置。旧数据库仍可能让普通 PHP 代码工作,但不能把它当成新连接复用能力已经满足。

常见问题

PHP 8.6 会要求所有用户安装 Autoconf 2.71 吗?

不会。RFC 针对的是从 Git 源码构建的场景;官方发布压缩包含有预生成的 configure

只升级 Autoconf 就能解决构建失败吗?

不能。C11 编译器和所选扩展的开发库仍要满足要求,Autoconf 只解决生成配置脚本这一层。

数据库版本检查应该放在 buildconf 前吗?

不建议。数据库版本和 COM_RESET_CONNECTION 属于运行时连接能力,应在 PHP 编译成功后用独立回归用例检查。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>