Closed rgmiller closed 10 months ago
Note: We aren't setting --rpath
when we link against libcrypto. Furthermore, spack no longer modifies LD_LIBRARY_PATH as part of its module loading process. This results in an odd edge-case: If the user is using a spack environment, then UnifyFS will compile and link against the spack-built version of libcrypto, but at runtime might still dynamically load the system-provided version of libcrypto. (The version number of the libcrypto libraries would have to match, but that doesn't mean the libraries are exactly the same.)
Do we want to do anything about this? And if so, should it be part of this PR or a new one?
Thanks, @rgmiller !
Ensure all parts of UnifyFS build and link against the version of libcrypto set by the configure script.
Description
This change adds the variables set by the configure script (OPENSSL_CFLAGS and OPENSSL_LIBS) to the UNIFYFS_COMMON_BASE_FLAGS and UNIFYFS_COMMON_BASE_LIBS variables to Makefile.mk.
Motivation and Context
Without this change, it's possible that not all components of UnifyFS will be linked against the same libcrypto.so library. (Full details in the description for issue 792.)
How Has This Been Tested?
Built UnifyFS both with and without the change. Without the change, unifyfsd and unifyfs-stage depended on different instances of libcrypto. With the change, everything used the same libcrypto.
Types of changes
Checklist: