autoconf：使用 `PKG_CHECK_EXISTS` 时，`PKG_CONFIG_PATH` 在 `configure.ac` 中不起作用

Question

我想检查我的自定义中是否存在

gmodule

PKG_CONFIG_PATH

// configure.ac
AC_SUBST([PKG_CONFIG_PATH],"./glib/lib/x86_64-linux-gnu/pkgconfig/")
PKG_PROG_PKG_CONFIG
PKG_CHECK_EXISTS([gmodule-2.0],[],[
    AC_MSG_ERROR(can't find gmodule in glib-2.0)
])

但是我有以下错误：

checking for libunwind.h... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
configure: error: can't find gmodule in glib-2.0

我 100% 确定 gmodule-2.0.pc 在我的自定义路径中：

> ls ./glib/lib/x86_64-linux-gnu/pkgconfig/                            
gio-2.0.pc  gio-unix-2.0.pc  glib-2.0.pc  gmodule-2.0.pc  gmodule-export-2.0.pc  gmodule-no-export-2.0.pc  gobject-2.0.pc  gthread-2.0.pc

我也可以使用pkg-config来查找

gmodule-2.0

：

> PKG_CONFIG_PATH="./glib/lib/x86_64-linux-gnu/pkgconfig/" pkg-config gmodule-2.0 --cflags 
-pthread -I/home/xxx/fuzz/test/StochFuzz/glib/include -I/home/xxx/fuzz/test/StochFuzz/glib/include/glib-2.0 -I/home/xxx/fuzz/test/StochFuzz/glib/lib/x86_64-linux-gnu/glib-2.0/include

我想念什么吗？

Answer 1

我想念什么吗？

看起来你很期待这个......

AC_SUBST([PKG_CONFIG_PATH],"./glib/lib/x86_64-linux-gnu/pkgconfig/")

...导致

configure

在运行

./glib/lib/x86_64-linux-gnu/pkgconfig/

时使用

PKG_CONFIG_PATH

作为

pkg-config

。在那种情况下，你至少错过了那个

• AC_SUBST()

  的目的是创建一个输出变量。如果你想将 pkg-config 路径传递给你的 Makefile，你需要一个输出变量，但这与你的

  configure

  脚本没有直接关系。

• 虽然

  AC_SUBST

  确实设置了指定的shell变量的值，如果你为它指定一个值，
  1. 它不一定export那个变量。
  2. 赋值不一定出现在

     configure

     脚本中对应宏在

     configure.ac

     中的位置。

• 如果您正在尝试使用与您的项目捆绑在一起的组件（如果所需的详细信息由您自己的源代码树中的 pkg-config 数据提供，那肯定是您正在做的事情）那么 pkg-config 就太过分了。只需将所需的路径和标志放入您的

  Makefile.am

  文件中，或者如果您不使用 Automake，则直接放入您的

  Makefile.in

  文件中。

如果您坚持使用 pkg-config 执行此操作，那么这种变化可能会从

PKG_CHECK_EXISTS

宏中引发您想要的行为：

# configure.ac
PKG_CONFIG_PATH=./glib/lib/x86_64-linux-gnu/pkgconfig/
export PKG_CONFIG_PATH
PKG_PROG_PKG_CONFIG
PKG_CHECK_EXISTS([gmodule-2.0],[],[
    AC_MSG_ERROR(can't find gmodule in glib-2.0)
])

如果您还需要将您的自定义

PKG_CONFIG_PATH

传达给您的makefile，那么您可以添加...

AC_SUBST([PKG_CONFIG_PATH])

... 但你不应该。尽管在这种情况下您根本不应该使用 pkg-config（见上文），但当您do 在 Autotools 构建系统中使用 pkg-config 时，最好的使用方式完全在

configure

.在那里提取所需的路径和标志，并通过输出变量将它们传送到您的 makefile。

Answer 2

如果你正在做某种超级构建，并且希望你正在配置的任何东西都使用你已经构建并安装到

./glib/

中的本地 glib，那么正确的方法就是不要做任何奇怪的事情你的

configure.ac

，它是用你的自定义运行

configure

PKG_CONFIG_PATH

：

$ PKG_CONFIG_PATH="./glib/lib/x86_64-linux-gnu/pkgconfig/" ./configure ...

但是，如果你正在构建一些使用共享库的东西，那么以这种方式构建它会让你头疼，因为你已经有效地使本地

glib/

目录树成为运行时依赖项。你将需要在你的二进制输出上设置一个

RUNPATH

（又名

RPATH

），这样他们才能真正找到他们的库，即使这样运行时也会很脆弱并且不容易移动。

如果你做这样的事情，我会感觉好多了，

$ cd ~/superbuild
$ mkdir runtime
$ cd glib_src
$ ./configure --prefix=$(realpath $(pwd)/../runtime) ...
$ make
$ make install
$ cd ../mypkg_src
$ PKG_CONFIG_PATH="$(realpath $(pwd)/../runtime/lib/x86_64-linux-gnu/pkgconfig)" \
  ./configure --prefix=$(realpath $(pwd)/../runtime) ...
$ make
$ make install

...这表明您正在将所有超级构建输出安装到同一个位置（顶层

runtime/

目录下的

superbuild

树），而不是（看似）为每个依赖项安装不同的安装树。

你仍然需要一个

RUNPATH

在

~/superbuild/runtime/lib/x86_64-linux-gnu/

中针对库构建的所有内容，但是你可以将它设置为

$ORIGIN/../lib/x86_64-linux-gnu/

对于你安装到

~/superbuild/runtime/bin/

的二进制文件，以及

$ORIGIN

对于安装到

 的其他共享库~/superbuild/runtime/lib/x86_64-linux-gnu/

.

然后，你至少可以在事后移动

~/superbuild/runtime/

的内容，只要它们都保持在相对于彼此的相同位置。

但是这种事情不应该硬编码成

configure.ac

。

PKG_CONFIG_PATH

，至少，应该始终设置outside of

configure

——如果你愿意，你可以在

build.sh

中编写超级构建步骤，但不要用错误的、脆弱的假设来削弱你的配置脚本。

（更好的是，不要为此使用 autotools。它非常不适合。例如，CMake 会自动在它在

build

目录中生成的二进制文件上设置RUNPATHs，所以你甚至没有在安装时间之前担心任何这些。它的

FetchContent

模块可以快速将依赖包，甚至是基于autotools的包合并到一个超级构建中。）