is there a configure test that detects invalid symbolic links?

Question

I am looking for a resolution to https://trac.mpich.org/projects/mpich/ticket/1888. The configure test correctly finds libpciaccess.so, which is a symlink that points at a non-existent second symlink rather than the correct one, hence the ultimate resolution of the desired shared object fails.

$ 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 root 35K 2011-10-10 16:16 /usr/lib64/libpciaccess.so.0.10.8

Does anyone know a good way to check for bad symbolic link resolution using configure?

Thanks!

Answer 1

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.