| layout | page |
|---|---|
| title | Dynamic OpenSSL with FIPS Support in vcpkg Build |
| nav_order | 8 |
| parent | Getting-Started |
By default, Gluten's vcpkg build statically links OpenSSL into the native libraries (libvelox.so and libgluten.so). However, in environments requiring FIPS (Federal Information Processing Standards) compliance or dynamic OpenSSL linking, Gluten now supports building with dynamically linked OpenSSL.
This feature is particularly useful for:
- FIPS compliance: Organizations requiring FIPS 140-2/140-3 validated cryptographic modules
- Security updates: Easier OpenSSL security patching without rebuilding Gluten
- System integration: Using system-provided OpenSSL libraries
- vcpkg-based build system (requires
enable_vcpkg=ON) - OpenSSL development libraries installed on the system
- Supported platforms: x86_64 and aarch64 Linux
To enable dynamic OpenSSL linking with FIPS support, set the VCPKG_DYNAMIC_OPENSSL environment variable:
export VCPKG_DYNAMIC_OPENSSL=ON
./dev/buildbundle-veloxbe.sh --enable_vcpkg=ONWhen VCPKG_DYNAMIC_OPENSSL=ON is set:
- vcpkg Configuration: The
dynamic-opensslfeature is enabled invcpkg.json, which includes OpenSSL with FIPS support - Triplet Override: Custom vcpkg triplets (
x64-linux-avx.cmakeandarm64-linux-neon.cmake) detect the environment variable and switch OpenSSL from static to dynamic linkage - Build Process: The
init.shscript adds the--x-feature=dynamic-opensslflag to vcpkg install - Library Packaging: OpenSSL shared libraries are excluded from static linking but must be available at runtime
NOTE: At runtime,
LD_LIBRARY_PATHmust include the OS-provided OpenSSL libraries, includinglibssl.so,libcrypto.so, and the FIPS-certifiedfips.so. These libraries must be available and loadable; otherwise, Gluten will fail to start. At the time of the Gluten 1.7 release, Gluten is built and tested with OpenSSL3.5.2. Users should ensure that the OpenSSL libraries (libssl.soandlibcrypto.so) available at runtime are compatible with those used during linking. To minimize the risk of ABI or API compatibility issues, we recommend using the same major OpenSSL version for both build-time and runtime environments.