configure报错主因是构建工具链缺失，需按发行版安装build-essential或development tools及-devel头文件包；编译链接失败多因库路径未识别或缺少静态库；安装后需更新path和ld.so缓存；推荐使用--prefix=$home/local避免系统污染。
configure 时提示 command not found 或找不到依赖库
不是 configure 脚本坏了，而是它依赖的构建工具链没装全。Linux 发行版默认不带编译环境，./configure 本质是 shell 脚本，会调用 gcc、make、pkg-config 等命令，缺一个就报错。
- Debian/Ubuntu 上先跑：
sudo apt install build-essential pkg-config autoconf automake libtool - RHEL/CentOS/Fedora 上对应是：
sudo dnf groupinstall "Development Tools"+sudo dnf install pkgconfig autoconf automake libtool - 常见“找不到
libssl”类错误，别急着搜源码包，先装开发头文件：比如libssl-dev（Debian）或openssl-devel（RHEL） -
pkg-config特别关键——很多 configure 靠它查库路径和版本，装了库但没装-devel包，pkg-config --modversion xxx就会失败，configure 也就跟着哑火
make 编译卡住或报 undefined reference
这通常不是代码问题，而是链接阶段出错：目标文件生成了，但最终拼成可执行文件时，发现某个函数符号找不到定义。根源常在 configure 阶段没正确识别依赖库，或者手动加了 --with-xxx 却没配对提供 .so 或 .a 文件。
- 检查 configure 输出末尾有没有
checking for xxx... no，尤其是你明确需要的功能项 - 运行
make V=1（不是make verbose）看实际调用的gcc命令，确认-lxxx和-L/path/to/lib是否出现、路径是否真实存在 - 如果自己编译过依赖（比如先装了新版 OpenSSL），确保
LD_LIBRARY_PATH不影响 configure 检测（configure 是运行时检测，不是链接时），但编译后运行可能需要它 - 静态链接时注意：
--enable-static可能要求所有依赖都提供静态库（.a），而多数发行版默认只装动态库
make install 后命令找不到或报 shared library not found
make install 默认把二进制丢进 /usr/local/bin，库文件进 /usr/local/lib，但系统默认不查这两个路径。这不是安装失败，是 PATH 和 ld.so 缓存没更新。
- 临时解决：运行前加
export PATH="/usr/local/bin:$PATH"；运行时报库缺失，加export LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" - 永久生效更稳妥：把
/usr/local/bin加进/etc/environment或用户 shell 的~/.profile；对库路径，新建/etc/ld.so.conf.d/local.conf，写入/usr/local/lib，再跑sudo ldconfig - 别直接
make install覆盖系统关键工具（比如用源码装的bash或coreutils），容易让系统无法登录——优先用--prefix=$HOME/local装到用户目录下测试 -
strip命令可减小二进制体积，但调试时别开，否则gdb无法读符号；有些软件的Makefile在install里自带 strip，留意 configure 选项如--disable-stripping
想跳过 configure / make 流程直接运行源码
绝大多数 C/C++ 源码软件没有“免编译运行”这回事。所谓“源码包”不是脚本，是待编译的中间态，连 ./configure 都是自动生成的（由 autogen.sh 或 autoreconf 产生）。真想绕过，只有两种现实路径：
- 确认项目是否支持 Meson/Ninja：有些新项目已弃用 autotools，改用
meson setup builddir && ninja -C builddir，速度更快，报错更直观 - 找 prebuilt binary：官网有时提供
.tar.xz二进制包（含bin/和lib/），解压即用，但得核对ldd ./binary输出，确认 glibc 版本兼容（比如 CentOS 7 的 glibc 2.17 跑不了为 Ubuntu 22.04 编译的二进制） - 容器化是更现代的解法：Docker 官方镜像或
linuxserver.io提供的镜像常预装好编译环境，git clone && make在容器里跑，干净又隔离
configure 的缓存逻辑、aclocal 的宏路径、libtool 的 .la 文件处理……这些细节不会报错，但会让第二次编译行为突变。最省心的做法，每次从干净源码开始，用独立 build/ 目录，而不是在源码根目录下直接 ./configure。
