Fix Windows installers #3113
Fix Windows installers #3113
Conversation
The Windows installer provides the SRT libraries for all possible architectures. However, SRT needs OpenSSL and OpenSSL for Windows cannot install its Arm64 libraries on Intel systems. More precisely, on Arm64 systems, we may install OpenSSL libraries for x86, x64 and Arm64. However, on Intel systems, OpenSSL libraries can be installed for x86, x64 only. This is an unfortunate limitation of the OpenSSL installer for Windows. As a consequence, when building the libsrt installer in a Windows Intel system, the installer now contains the x86 and x64 libraries only. To build a libsrt installer with the binaries for the three architectures, the build must be performed on a Windows Arm64 system. This is not easy to achieve on automated CI systems where Windows systems are usually Intel only. Manually, the easiest way to get a Windows Arm64 is to install a virtual machine on a recent Mac.
|
Wow, that's an interesting issue I would not see coming. 🙂 |
There are always lots of delivery and packaging problems when using external libraries on Windows. That's why I made some effort in properly packaging libsrt on Windows. To avoid pain when preparing the TSDuck build on Windows. Unfortunately, the pain is transitive to dependencies. In the TSDuck project, I took care to always choose native tools and libraries, depending on the OS, to reduce the risks. For cryptography, I use OpenSSL on Linux and macOS but the native Microsoft BCrypt library on Windows. To avoid the current issue, precisely. Same with libcurl on Linux and macOS but the native Microsoft WinInet library on Windows. Only specific libraries such as libsrt need to be used everywhere. And this is sufficient to bring problems, as you can see 😟 |
|
I just think this is a kind of problem to be solved on the OpenSSL side. But then, I guess, they are not willing to fix it... |
The OpenSSL Windows binaries for Windows are delegated to Shining Light Productions (https://slproweb.com/products/Win32OpenSSL.html). I have sent them a description of the problem. Since they are dedicated to the Windows world, they may understand the inconsistent situation of having a full multi-target development solution (Visual Studio) and the inability to get their libraries in one specific situation. I am not sure they will do something but I still have hope. |
|
@ethouris, this is also the reason why I never use UNIX libraries such as OpenSSL, libcurl and the like on Windows. These libraries (or applications) were developed by Unixians for Unixians and porting them to Windows is always a pain, resulting in clunky packaging and building constraints. Don't get me wrong, I consider myself as a Unixian too (macOS and Linux) and I hate Windows. But as a project owner, I am forced to admit that many users remain on Windows and I want to bring the same quality on all platforms. |
|
Yeah, same about me, and for several aspects I have found quite the same situation - not exactly for libraries, but also for critical builtin system solutions. I tried once to improve efficiency of the SRT's receiver worker thread (which actually manages the whole transmission workflow, regardless of its name) and tried to involve some system event polling to manage incoming events (timer elapsing as well as incoming data on the socket). It also turned out that it better be done using the system-provided facilities, especially on Windows. Of course, real portability exists - but only if you have something like C++ standard library. The C++ standard committee defines the library and it's the Microsoft's problem how it implements it. Problems are obviously there, but then Microsoft must clearly describe how well it supports it. That's why in the "sync" part on Windows we rely on the C++11 standard library. Frankly, I don't exactly understand, what system-specific is there in the encryption library that it can't be defined portable way. But still, real portability is when this library is provided by the main compiler vendor and guaranteed by it - such as with the case of the C++ standard library - and not exactly when it was "ported from" some posix-like system. Seems like C++ standard library should provide this at some point. |
@ethouris, probably no portable issue inside the crypto library. The issue is the availability of that library when building on Windows. And the real issue is not how much time you spend on setting up your system in order to get to a situation where you can finally build your application. The real issue is how do you build your application on any user's Windows machine, when that user wants to rebuild your application. Or, more realistically, when you build on a clean empty Windows VM in the GitHub CI/CD platform. That's why I use OpenSSL on UNIX systems and BCrypt on Windows. That's why I call Of course, I hide this into a set of C++ classes which provide a uniform API for the rest of the application. I understand that it may not be easy to do that in libsrt but is would be great to get rid of OpenSSL dependency on Windows. There is also a underestimated cost of using build managers such as CMake. They pretend to hide the complexity of the system-specific configurations and you just say "use OpenSSL" to CMake. However, CMake just pushes the dirt under the carpet. It "just works"... provided that you spend a considerable effort in setting up the system. I have one question, though. Because CMake just "uses OpenSSL", we don't know what libsrt actually uses from OpenSSL libraries. Does libsrt only use encryption features from |
We also have some uniform API in haicrypt subproject (although it's in C due to the nature of this code), and through that we support 3 different encryption libraries (or even 4 - I don't remember if Botan support is already in the release). Maybe if you could extract this uniform API into an independent library, it could allow providing the "portable encryption support" for all others.
Well, support for BCrypt would be possible, but assigning work resources for this job is the matter of someone's interests.
Huh, tell me about it - #3107. I hate CMake, really, by various reasons, and trying to be smarter than the developer is also one of them. I wanted to personally rely exclusively on pkg-config for such things, but even this somehow cannot be a standard for all libraries.
Well, I was also surprised about some things there, and Jean has made some discoveries - look at the issue above, that could be kinda interesting. Anyway, somehow I managed to do so that cmake added libcrypto, but not libssl. And the linkage passed correctly. |
|
I assume SRT does not require libssl, but worth confirming. |
Interesting. As far as I am concerned, I dropped all other crypto libraries and kept only OpenSSL in the UNIX world. 20 years ago, a colleague of mine - a true cryptologist - used to say that OpenSSL was the "worst crypto library ever". But those days are gone and considerable improvements were achieved in OpenSSL since then. I recently made some comparative benchmarks on several crypto libraries (not Botan though) and OpenSSL is always faster. See https://github.com/lelegard/cryptobench for details and results. Nowadays, most CPU's have crypto or vector instructions which speed up the processing and contributors upstream the corresponding assembly code almost exclusively to OpenSSL. Of course, I wouldn't say the same thing about small embedded devices where alternative libraries may better fit the constraints. If you are interested in OpenSSL AES benchmarks on various processors, you can check this: https://github.com/lelegard/aesbench |
|
I have not yet received any feedback from Shining Light Productions about the issue of installing Arm64 OpenSSL libraries on Intel systems. In the meantime, as a proof of concept, I wrote a script which downloads and installs the OpenSSL binaries for the 3 architectures and then repackages the headers and all libraries in one single installer. Because of the current issue, the script shall be run on an Arm64 Windows system. But the resulting installer can be used anywhere as some kind of universal OpenSSL SDK for Windows, for all targets. The script is in a new repo: https://github.com/lelegard/openssl-winlibs I have produced one release OpenSSL-WinLibs-3.4.1.exe. I tested it on an Arm64 and a x64 Windows system. A small example (included in the installer) can be built for all three architectures, on any build system. We should still wait for an official position from Shining Light Productions about their OpenSSL binaries. This PoC is just a potential fallback. I would summarise the possible solutions as follow, in decreasing order of preference in terms of sustainability:
The last solution is the worst one because it pushes the burden onto another person (me as of today, someone else if it is taken over) who must be careful about new releases of OpenSSL binaries, rebuild and publish the OpenSSL-WinLibs kit. I wanted to prove that it is feasible but I would prefer to avoid it. The first solution has the advantage of relying on no third-party library on Windows. It is a pity but we have to admit that open source developers don't care about Windows developers when they release a library. OpenSSL is one of the few exceptions, where binaries are officially released in a timely fashion. But still, we run into a dire situation. Let's be convinced on this: relying on third-party libraries on Windows is always a problem, always, no exception, never. In my TSDuck project, whenever there is a native Windows library, I choose it. There are only three specialised open source libraries without native equivalent: libsrt, librist and libvatek. The three have consumed a significant part of my time, only for Windows. Surprisingly, the only third-party library which is perfectly and smoothly integrated in Windows is proprietary, not open source. This is the DTAPI from Dektec. What kind of crypto service do you use in OpenSSL? Symmetric only (AES)? Which modes? Or asymmetric as well (RSA, ECC)? That would give an idea of the complexity of using BCrypt. I use it in TSDuck for symmetric crypto in various chaining modes. So, this gives a working code template. |
|
@maxsharabayko, @ethouris, I also discovered severe performance issues with OpenSSL on Windows, compared to OpenSSL on Linux and macOS, and compared to BCrypt on Windows. Therefore, I opened the feature request #3116 to request the use of BCrypt on Windows instead of OpenSSL. |
As of now PBKDF2 and symmetric AES CTR with AEAD (GCM) and without. |
|
@maxsharabayko, I got a very positive response from the producers of the OpenSSL binaries for Windows. They now produce one "universal" installer which installs binaries for all architectures, on any architecture. Please don't merge this PR now. I will push a commit on the same branch using the updated installers. That should fix that specific build issue. (The OpenSSL performance issue on Windows as described in #3116 is still relevant). |
|
@lelegard Great news! |
|
Turn it into draft, if you want to prevent this from merging. Maybe it could be useful later. |
|
@maxsharabayko, I pushed a second commit in this PR which seems final. You may merge it. Before building the libsrt installers, you will need to run the script I have successfully completed the following tests on Windows:
So far, so good. |
|
Ok, I tried this out and uninstalled my OpenSSL first, then I ran the script and then the build. The installation script has eneded, but I can't see OpenSSL in a typical installation directory "C:\Program Files", nor can cmake find it (unlike when I have installed it manually). The script could have been at least a bit more informative about what it is doing. |
|
Ah, one more thing: after running this script I have weird changes in one file: (The form comes from my script, https://github.com/ethouris/git-tools/gvimdiff-git-wrapper - but I think clear enough) |
|
Hi @ethouris. After running Then, the script Sorry, I'm out for a few days without computer and it's difficult to copy/paste exact references from a phone. |
|
Meaning, I should not use |
|
I haven't checked your build script, sorry. I just modified scripts in the installer directory. You need to help CMake find OpenSSL with the two symbols. |
|
About the differences in the |
|
Yeah, but as I said, after I have run After I manually download and install the OpenSSL installer from the webpage - just I need to walk through the wizard - it installs in I understand that scripts have their specifics, but if I have trouble with properly using this script, other users will have them, too. If I need to feed the |
It won't work anyway. It is not only a matter of root location. It is also a matter of structure. The new installer has a different structure because each area, bin, include, lib, is split in three architecture-specific subdirectories. This is why I had to specify the two symbols to CMake. Just align the CMake call in your script to Anyway, OpenSSL on windows is a moving target to CMake. It breaks regularly. The first time I wrote the In short, nothing is reliable on the long term and it is safer to tell CMake where you have installed OpenSSL. Finally, I do not recommend to specify a non-default location during installation of OpenSSL. Because your script will work in your environment only. Automation requires standard installations and procedures. Otherwise, use the BCrypt library to get rid of all that crap 😉 |
|
Ok then, here is the session that I, as an average user, would do. What should I do next? (NOTE: |
|
Did you checkout the branch of my PR or did you pull the second commit? It looks like you are using an old version. |
|
Ok, I double checked, I had some kind of different version, so I updated. This time it complained also about lacking NSIS, but there is a script to download it, so after that it had all deps satisfied, but then I have this: The same error, at least the one about version.h, repeats then multiple times. It looks like also that this script is trying to build for every supported platform... not sure if that was the intent. |
|
The error about version.h means that CMake failed and could not generate it. And CMake failed because it couldn't find OpenSSL. The same script works on my two Windows 11 systems, a x64 laptop with native Windows and an Arm64 Windows VM on a Mac. The config is:
I am away for a few days without access to my computers. So I cannot tell you the exact versions. I will update when I'm back, in two days from now. As we both already agreed, CMake sometimes creates more problems than it solves and the relationship between OpenSSL and CMake on Windows has always been "complicated", to say the least. |
|
Ok, I repeated everything from scratch and everything seems to be fine - almost. At least the build succeded, The Not sure whether shared libraries were expected to be built; I find no *.dll files, but I found |
|
Ok. So now the problem is that the Arm64 build failed. And the obvious question is did you install the Arm compiler ? This is explained in the README file in the same directory.
|
|
And the shared libraries are not built. In an application which uses SRT and must be deployed in multiple places, the static libraries (libsrt and OpenSSL) avoid troubles. Windows is not Linux 😟 (unfortunately). |
|
Right, I didn't, but then would this script be completely useless if you didn't install the Arm64 compiler? My point is, if this script is going to compile for multiple platforms, the user should be able to choose, which platforms should be included. Be it even that by default it compiles for all platforms. And for shared libraries: I understand it makes little sense for shared libraries in this kind of installer, maybe vcpkg could do better here, but that's another story. I just wanted to make sure that this behavior was intended. |
|
The idea of that script is to build the official libsrt installer for publication in the GitHub release. So, it must embed all platforms. I can update it to make it more versatile. But honestly, apart from the SRT developers, who is interested in building libsrt in Windows? It is such a pain to build open source software on Windows (and this discussion just demonstrates this 😉) that users just want to grab ready-to-use binaries. |
|
Ok, if this script was intended to be run from CI to automatically build binary packages with the release, then availability of the compilers is the requirement. I was kinda hoping that it could be also useful for those who want to run Still, as for preparing the release binary packages, this functionality is useful, even if not exactly versatile. But as long as users don't demand more, I have no problem with that, unless @maxsharabayko has anything to add here. |
The Windows installer provides the SRT libraries for all possible architectures. However, SRT needs OpenSSL and OpenSSL for Windows cannot install its Arm64 libraries on Intel systems. More precisely, on Arm64 systems, we may install OpenSSL libraries for x86, x64 and Arm64. However, on Intel systems, OpenSSL libraries can be installed for x86, x64 only. This is an unfortunate limitation of the OpenSSL installer for Windows.
As a consequence, when building the libsrt installer in a Windows Intel system, the installer now contains the x86 and x64 libraries only. To build a libsrt installer with the binaries for the three architectures, the build must be performed on a Windows Arm64 system.
This is not easy to achieve on automated CI systems where Windows systems are usually Intel only. Manually, the easiest way to get a Windows Arm64 is to install a virtual machine on a recent Mac.
PS: Sorry for pushing a second PR on the topic in a couple of days. All my tests were done on a Windows Arm64 system. All went fine. The installer contained the libsrt binaries for the three architectures. I realized the problem when repeating the build on a Windows x64 system. The most frustrating part is that the only reason is the impossibility to get the OpenSSL libraries for Arm64 in binary form on Intel systems. I will check with the guys at Shining Light Productions if they can amend their delivery of OpenSSL on Windows.