| commit | d9f5f88b8790f6ba9cfe5d4809d1cab2b191df1c | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue Apr 15 12:05:41 2025 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Apr 15 11:09:55 2025 -0700 |
| tree | e3c88266f0120cc961f0b80023d60a8b6ad9207e | |
| parent | 45a865d6682a7bc989143d73466ade7728959324 [diff] |
Put all VS runtime dirs in PATH This fixes the SDE builders after https://boringssl-review.googlesource.com/c/boringssl/+/75008/ VS comes with some runtime dlls for things like the debug version of their C runtime. These are not generally available on Windows machines (notably not on our CI machines), so debug builds need to get them from MSVC. Annoyingly, those directories are not part of the SetEnv.{arch}.json files in MSVC, so I had to put them in by hand elsewhere. I attempted to match what the old package and the GN goop was doing, but it resulted in a mysterious error on 64-bit debug builds. So the version I landed just filtered by CPU. This worked except that win64_sde broke with a different error. Looks like the sde.exe launcher is 32-bit (though why it needs MSVC dlls, I'm not sure). After some more wrestling, it turns out the problem was the directory order! Due to a bug and some incorrect sorting, I put them in order sysarm64, sys64, sys32. The correct order is sys64, sys32, sysarm64. The order is actually significant. There are some x86_64 dlls in sysarm64 that confuse Windows. (arm64ec perhaps?) Anyway, go back to putting them all in there. This is probably also wrong, to be honest, but this matches what we were doing before. We can dig into this further later. Change-Id: Id8108f40baa761b50e30135f21a72345130ef729 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/78547 Commit-Queue: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: