Alien::Build::Plugin::Build::SearchDep: issues with mixed system and share installs

[shawnlaffan]

I just worked around an issue with Alien::Build::Plugin::Build::SearchDep where system paths were listed in the set of libs before any of the share installs. The issue with this is that the share aliens had equivalent but older packages in the same directory as the system alien. These older packages were then being used for later compilation of other modules instead of the ones packaged with the share installs, and the rpath of the linked XS .so file pointed to the system dir instead of including the shared paths.

In terms of the specific example, Alien::proj depends on Alien::libtiff and Alien::sqlite. My Ubuntu 20.04 instance has libproj-dev installed, thus there are system binaries for libproj, libtiff and libsqlite3 under /lib/x86_64-linux-gnu. Alien::libtiff is a system install but Alien::proj and Alien::sqlite are share installs, so the relevant libproj and libsqlite3 .so files live in the alien share dirs. The system libproj is 6.3.1, the shared alien version is 9.5.0.

Alien::proj (prior to v1.29) was built using Alien::Build::Plugin::Build::SearchDep as part of the build process. This found the system install of Alien::libtiff first and so Alien::proj->libs started with -L/lib/x86_64-linux-gnu.

When PDL was installed with Alien::proj it used that lib string. When the string was parsed by ExtUtils::Liblist, all the dependent libraries including libproj and libsqlite3 were found in /lib/x86_64-linux-gnu. The rpath of the relevant PDL .so file thus pointed only to that directory (due to the LD_RUN_PATH var in the Makefile) and the wrong version of libproj was called (details are sprinkled through PDLPorters/pdl#498).

The workaround I implemented in the Alien::proj alienfile was to exclude any system installs from the Build::SearchDep plugin call. This seems to have cleaned things up and the issue is avoided.

The question, then, is what should be done with Alien::Build::Plugin::Build::SearchDep?

I see two options, either or both of which could be implemented. First is to document the potential effect of system libs on rpaths and so forth for downstream compilation using the alien. Second is to add an option to ignore system aliens passed to the plugin. A bonus option might be to warn when a system alien is passed as an argument.

If the proposed updates make sense then I can work up a PR.