To build portable pre-compiled packages and Windows installers for major platforms.

[tregubovav-dev]

Motivation & Context

The TaurusTLS-Developers team has been supplying the Delphi, Free Pascal, and C++Builder developer communities with pre-compiled OpenSSL binaries through automated CI/CD builds at TaurusTLS-Developers/OpenSSL-Distribution tracking upstream releases.

We fully embrace and welcome the official OpenSSL binary distribution provided directly by the OpenSSL project. However, our consumers have specific platform requirements: they actively rely on pre-compiled Windows binaries for x86, x64, and ARM64EC.

The TaurusTLS team would like to assist you in integrating x86 and ARM64EC support into the official installer.

---

Why ARM64EC and x86?

• ARM64EC (Windows on Arm): While pure ARM64 works for standalone apps, toolchains like Embarcadero Delphi target the ARM64EC ABI to run natively on Windows on Arm devices while maintaining x64 interoperability.
• x86 (32-bit): 32-bit targets remain heavily used for active development, legacy integration, and debugging across the Delphi, Free Pascal, and C++Builder developer communities.

---

What we have working

In our pipeline, we have already resolved the toolchain details for these targets:

1. ARM64EC Target Configuration: Custom target handling /arm64EC, architecture-specific flags, warning suppressions, and correct archiver/linker machine types (/MACHINE:ARM64EC).
2. HybridCRT Linkage: Statically linking the VC runtime (/MT) while dynamically linking the Universal CRT (ucrt.lib), eliminating external vcruntime140.dll dependencies across all Windows architectures.
3. Multi-Architecture Packaging: Automated staging and packaging logic for multi-arch distributions.

---

What is the best path to contribute?

We would like to contribute this work upstream so consumers can get these platforms directly through the official trusted channel.

What is the preferred approach for the team? We can:

• Open a PR with our target configurations and build script adjustments.
• Help adapt the existing WiX/MSI packaging setup to include ARM64EC and x86 payloads.
• Assist with testing on GitHub-hosted windows-11-arm runners.

[tregubovav-dev]

Hi everyone,

Following up on our earlier post, we wanted to share the concrete technical solutions and findings we have developed.

To be clear, our goal is not to maintain a third-party distribution. Many of our users and enterprise customers have strict software supply chain security requirements that necessitate consuming pre-compiled, signed binaries directly from the official OpenSSL vendor channel rather than community rebuilds.

Because of this demand, we built a production-tested reference pipeline (TaurusTLS-Developers/OpenSSL-Distribution) to resolve the toughest platform, toolchain, and packaging hurdles. We would like to share these working solutions with the OpenSSL team as a reference and help adapt them directly into the official OpenSSL installer and distribution pipeline.

---

🚀 What We Have Implemented & Verified in Production

1. Windows: True ARM64X Dual-Architecture & HybridCRT

• ARM64X (Native ARM64 + ARM64EC in a single binary): Rather than maintaining conflicting DLL names for Windows on Arm, we developed a fusion pipeline that links native ARM64 and ARM64EC slices into true ARM64X binaries (libcrypto-3-arm64.dll, libssl-3-arm64.dll, providers, engines, and unified .lib import/static libraries). A single DLL seamlessly serves both Native ARM64 processes and ARM64EC/x64-emulated callers.
• HybridCRT Linkage: All Windows targets (x86, x64, ARM64X) are compiled with /MT and dynamically linked against ucrt.lib. This completely eliminates the external vcruntime140.dll dependency and avoids runtime mismatches.

2. macOS: Universal Binaries with System LibreSSL Coexistence

• Universal Fat Binaries (x86_64 + arm64): Compiled in parallel and fused via lipo into single universal archives (.a) and dynamic libraries (.dylib).
• Relocatable @rpath: We pre-configure relative @rpath and @loader_path headers using install_name_tool. This allows OpenSSL to be embedded directly inside macOS app bundles and coexist alongside macOS's system-provided LibreSSL without any library collisions.

3. Linux: Relocatable Packages with Distro OpenSSL Coexistence

• Dynamic $ORIGIN RPATH: Compiled with -Wl,-rpath,'$ORIGIN', allowing portable OpenSSL deployments to run side-by-side with distro-bundled OpenSSL installations (e.g. /usr/lib64) without requiring root permissions or polluting global LD_LIBRARY_PATH.

4. Windows Installers & Packaging

• InnoSetup Multi-Architecture Setup (.exe): A single unified setup executable that autodetects CPU architecture at runtime, deploys matching binaries (x64, x86, or ARM64), supports Per-Machine (%ProgramFiles% / %ProgramFiles(x86)%) and Per-User (%LocalAppData%\Programs) modes, and includes an optional 32-bit compatibility mode on 64-bit Windows.
• MSIX Framework Packages (.msix): Published as standalone architecture Framework packages (<Framework>true</Framework>) for clean side-by-side deployment under WindowsApps and consumable via <PackageDependency>.

---

🤝 Collaboration & Upstream Alignment

You can inspect our live pipeline and test the resulting release packages directly at:
👉 TaurusTLS-Developers/OpenSSL-Distribution

Our primary goal is to help enable the developer community to receive modern, multi-architecture binaries and installers directly from the official OpenSSL project.

We are very open to collaborating and adjusting our pipeline, build mechanisms, and installer recipes to align with the OpenSSL team's specific requirements, signing infrastructure, and project standards.

Please let us know your thoughts on this direction and how we can best assist!

[jogme]

Hi, we will discuss it internally and get back to you soon!

[tregubovav-dev]

Thank you @jogme for the response.