Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

statically build in openssl instead of mbedtls #796

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

qrkourier
Copy link
Member

No description provided.

@qrkourier qrkourier linked an issue Feb 9, 2024 that may be closed by this pull request
@scareything
Copy link
Member

scareything commented Feb 9, 2024

It's best to link with shared libraries that are provided by the distro when possible. This way zet benefits from any updates to the libraries after zet was installed. There are two cases were we want to avoid using shared openssl libs:

  1. Builds that are made available from GH releases. We want these builds to have the broadest distro/version compatibility possible, since we don't know and control which dsitro people will be using. Older distros (especially older Debian-based distros) have older openssl libraries that use different/versioned filenames for the .so, and newer distros/versions generally do not make the older openssl versions available. So even if we linked with the older openssl on an older distro, it would not work on contemporary distros.
  2. Packaged builds for distros that provide very old openssl versions with incompatible APIs that prevent ZET/csdk builds from succeeding.

The trick to linking static or dynamic openssl libraries is in the vcpkg setup. Including openssl in vcpkg.json will result in the openssl libraries being downloaded and built (statically) by vcpkg - unless there is a vcpkg port overlay for the "openssl" dependency that specifies some hokus-pokus (the only doc I've seen is a blog) that tells vcpkg to use the one provided by the system.

So this project sets up a "default" set of vcpkg overlays that specify using the system-provided (and shared) libraries for packages that are universally available on our supported distros (and we could even expand the "default" overlays to use more distro-provided libraries (libllhttp, sodium, probably others)), and older distros/versions that provide incompatible and/or inadequate libraries have their own directory for vcpkg overlays. The "default" overlays are intended to be used for contemporary distros.

So, I think we want to do exactly this when we go back to using openssl.

@qrkourier
Copy link
Member Author

In addition to the differences in #707, we'd need to revert the vcpkg.jso dependency to openssl as was the case in that branch at the time.

The vcpk.json file currently declares mbedtls only.

Base automatically changed from document-openssl-build to main February 22, 2024 15:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

build release artifacts with OpenSSL instead of Mbed-TLS
2 participants