我正在寻找解决方案https://trac.mpich.org/projects/mpich/ticket/1888。配置测试正确地找到了 libpciaccess.so，这是一个指向不存在的第二个符号链接而不是正确的符号链接的符号链接，因此所需共享对象的最终解析失败。
$ ll /usr/lib64/libpciaccess.so*
lrwxrwxrwx 1 root 22 2012-09-06 11:37 /usr/lib64/libpciaccess.so -> libpciaccess.so.0.10.2
lrwxrwxrwx 1 root 22 2012-04-05 12:25 /usr/lib64/libpciaccess.so.0 -> libpciaccess.so.0.10.8
-rwxr-xr-x 1 根 35K 2011-10-10 16:16 /usr/lib64/libpciaccess.so.0.10.8
有谁知道使用配置检查错误符号链接解析的好方法？
谢谢！
If you use AC_CHECK_LIB, the configure test will link a test program to the library. If the symbolic link is orphaned, that test will fail. However, since this package is using pkg-config, AC_CHECK_LIB is almost certainly not being invoked. This is a fundamental flaw with PKG_CHECK_MODULES; the configure script is relying on information provided by the user through the *.pc files but is not validating that data. This is a bit of a kludge, and I've never tried it (because I believe the correct solution is to stop using PKG_CHECK_MODULES), but it seems that you could simply invoke PKG_CHECK_MODULES and immediately append to LDFLAGS and then call AC_CHECK_LIB to validate the flags. This would at least give the configure script a chance to fail rather than having the build fail.
--edited to omit following rant, which is retained for historical accuracy and because sometimes rants are a good thing, and it's hard to know when.--
Attempting to subvert autoconf by allowing specific library paths to be added via --with-libname flags is a strategy destined to failure. The list of paths to be searched for libraries is intended to be specified by the user to the configure script via LDFLAGS, and attempting to get the linker to select various libraries in the search tree in a different ordering is beyond the scope of autoconf.
In other words, it looks like this user has version 0.10.8 installed in the linker's search path before version 0.10.2, so the configure script is quite correctly linking to the 0.10.8 version. The maintainers of the package are lying to the user by providing a --with-libname flags that pretend to provide more features than the linker allows. Also, the user has lied to the configure script by providing package config files that do not accurately reflect the state of the system, and the maintainers are encouraging that falsehood by using PKG_CHECK_MODULES. This is one more example of why pkg-config should not be used in conjunction with automake. The bug will go away when the maintainer stops lying to the user, and the user stops lying to the configure script. In other words, the user needs to get their *.pc files in order, and there's nothing the maintainers can do to help beyond discontinuing their misplaced reliance on pkg-config
To further clarify, the configure script is correctly determining that the necessary library is available. However, the build is driven by data taken from the user's .pc files which is not checked by the configure script. This is a mismatch that is created by the use of PKG_CHECK_MODULES and is a significant reason that package maintainers should be discouraged from using PKG_CHECK_MODULES. The fix is for the user to fix their .pc files.