ldd-check test pipeline failures

[murraybd]

While I've been adding the ldd-check test pipeline to a variety of packages it has only been to ones which pass testing. There are also many packages for which the ldd-check test pipeline fails and the majority of those are likely due to missing dependencies e.g. the nginx and mesa changes in #40553.

This is an overarching issue for such failures.

[murraybd]

• airflow fails ldd-check test pipeline #40831
• aws-cli-2 fails ldd-check test pipeline #40833
• couchdb-3.3 fails ldd-check test pipeline #40836
• checkov fails ldd-check test pipeline #41002
• collectd fails ldd-check test pipeline #41003
• crfsuite fails ldd-check test pipeline #40837
• mlflow fails ldd-check test pipeline #40838
• mysql-9.1 fails ldd-check test pipeline #40834
• neon fails ldd-check test pipeline #40839
• openmp-16 fails ldd-check test pipeline #40840
• openmp-17 fails ldd-check test pipeline #40841
• percona-server-9.0 fails ldd-check test pipeline #40835
• superset fails ldd-check test pipeline #40842
• kubeflow-pipelines-visualization-server fails ldd-check test pipeline #40843
• firefox fails ldd-check test pipeline #41004
• freerdp-libs fails ldd-check test pipeline #41300
• kserve fails ldd-check test pipeline #41304
• kubeflow-katib fails ldd-check test pipeline #41305

[a-crate]

#41002, #40838, #41304, #41305 are cases where a python module brings a shared object with it, and then that shared object links against a 2nd shared object brought by the same module.
In this case SO1 links against SO2 using just the library name (instead of a relative path), which the python interpreter allows by loading objects in the same directory before looking elsewhere.

ldd doesn't do this by default, the test procedure will have to add the object's directory to LD_LIBRARY_PATH for python modules to test this.

#40831, #40843, #40842 have cases of this but they also have some other ldd failures unrelated to python stuff

[murraybd]

#41002, #40838, #41304, #41305 are cases where a python module brings a shared object with it, and then that shared object links against a 2nd shared object brought by the same module. In this case SO1 links against SO2 using just the library name (instead of a relative path), which the python interpreter allows by loading objects in the same directory before looking elsewhere.

ldd doesn't do this by default, the test procedure will have to add the object's directory to LD_LIBRARY_PATH for python modules to test this.

Will that only cause the test to pass i.e. does something more need to be done for the package to be fully functional?

[a-crate]

It will only cause the test to pass, but nothing more needs to be done as the packages are already fully functional.