FelixYBW commented on PR #11444: URL: https://github.com/apache/gluten/pull/11444#issuecomment-4559296216
> LGTM. Thanks. cc @FelixYBW > > Not sure if users will prefer linking against OS-installed, certified OpenSSL libs at build time. If so, we could allow bypassing the vcpkg OpenSSL build and let CMake find the system libs instead. Since this isn't determined yet, we can do the follow-up if needed in the future. > > Could you document this clearly in a separate PR for users to reference? Perhaps, we can include the following clarifications. Thank you. > > 1. At runtime, `LD_LIBRARY_PATH` should point to the OS-provided OpenSSL package, which includes `libssl.so`, `libcrypto.so`, and the FIPS-certified `fips.so`. > 2. Users should ensure compatibility between the OpenSSL libraries (`libssl.so` and `libcrypto.so`) used at link time and those available at runtime. We recommend using the same OpenSSL version for both to avoid potential issues. @philo-he, you are right. Ideally, we should link to libssl in the target system. We have below choices: 1. link the version in vcpkg, load the same system version on target machine. -- no issue 2. link the version in vcpkg, load different system versions on target machine. -- potential issue 3. link the version in vcpkg, release the libssl.so in vcpkg with Gluten jar together, set LD_LIBRARY_PATH to the released one -- no issue. 4. link the version in dev system, load the same version on target machine. -- no issue. 5. link the version in dev system, load different version on target machine. -- potential issue If 2 or 5 happens, developer either need to update the version in vcpkg/dev system or the one on target system. We just think openssl is stable enough, linking with vcpkg is much easier than system one. Let's try this solution first, and switch to yours once we encounter issues. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
