-
Notifications
You must be signed in to change notification settings - Fork 568
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
Add support for building with clang-cl #4255
base: master
Are you sure you want to change the base?
Conversation
6b32b1e
to
630d6f1
Compare
It turns out the aforementioned test failure isn't specific to the clang-cl build - it happens with MSVC too, I think its failing because my Windows VM doesn't have the "D-TRUST Root Class 3 CA 2 EV 2009" certificate the tests are looking for. |
That's certainly possible. If I recall correctly, the certstore tests are looking for more than one cert. so if it fails for just that one, you're probably right. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the failing test: Let's try to assume the existence of a different certificate. Apparently the D-Trust certificate isn't as wide-spread.
See: #4280
@solemnwarning could you rebase to master and see if the test succeeds on your platform now? |
I rebased onto master and the tests still failed... they do pass if I import the "D-TRUST Root Class 3 CA 2 EV 2009" certificate into the trust store though, so clearly my test VM is lacking certificates that everyone else apparently has. Regarding |
I added that for a change in the tests. So if the unit tests (
👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested on my windows environment and unfortunately the linker workaround doesn't seem to work for me. Or am I doing something wrong?
Also: I added a few commits that, I think, are worthwhile to add here: https://github.com/reneme/botan/commits/clang-cl/
- a CI job on Windows, and
- dedicated detection of 'clang-cl' and its version.
f3f45bc
to
6171bd3
Compare
This commit allows building with the Visual Studio LLVM toolchain by passing --cc=clangcl to the configure.py script.
6171bd3
to
cce2b6d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, apart from the two open discussions in p11.h
.
@@ -40,7 +47,7 @@ | |||
#pragma pack(push, cryptoki, 1) | |||
#endif | |||
|
|||
#include "pkcs11.h" | |||
#include <pkcs11.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can imagine the quote-based include might have been on purpose here. We do ship the upstream pkcs11 headers in the same include directory. There might be a case for preferring those over some system-provided ones. @randombit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not recall the reasoning on this one. I guess if we end up picking up a system provided header that's ok as long as it's recent enough.
@@ -3,7 +3,7 @@ | |||
* configure.py to determine the compilers version number. | |||
*/ | |||
|
|||
#if defined(_MSC_VER) | |||
#if defined(_MSC_VER) and !defined(__clang__) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this cause us to detect the compiler as clang
(vs clangcl
)? I would think what we'd want is an additional check
#if defined(_MSC_VER) && defined(__clang__)
CLANGCL __clang_major__ __clang_minor__
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This detects the version only. Guessing the compiler happens before even "running" the detect_version.cpp procedure.. That said:
- it probably doesn't hurt to handle clang-cl explicitly here,
- we should look into 'guessing' clang-cl correctly.
Right now, I wouldn't be surprised if the configure script would only pick up clang-cl when it is asked to do so explicitly.
@@ -40,7 +47,7 @@ | |||
#pragma pack(push, cryptoki, 1) | |||
#endif | |||
|
|||
#include "pkcs11.h" | |||
#include <pkcs11.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not recall the reasoning on this one. I guess if we end up picking up a system provided header that's ok as long as it's recent enough.
@@ -10,7 +10,7 @@ LANG_EXE_FLAGS = %{cc_lang_binary_linker_flags} | |||
CXXFLAGS = %{cc_compile_flags} | |||
WARN_FLAGS = %{cc_warning_flags} | |||
|
|||
LDFLAGS = %{ldflags} %{cc_compile_flags} | |||
LDFLAGS = %{ldflags} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if cc.basename == 'msvc' and variables['cxx_abi_flags'] != '': | ||
# MSVC linker doesn't support/need the ABI options, | ||
# just transfer them over to just the compiler invocations | ||
# On MSVC, the "ABI flags" should be passed to the compiler only, on other platforms, the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These shenanigans seem to suggest that we might end up with something that builds in CI but not on a developers machine, which isn't helpful. Is the issue here that Clang really dislikes /MD
/etc during the link step?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm recalling correctly, link.exe
ignores (and warns on) those flags, while lld-link.exe
errors on them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is relevant to #4424.
Are either of you anticipating me making any changes on this PR? The remaining points seem to be a bit "maybe do something". |
sse2 -> "-msse2" | ||
ssse3 -> "-mssse3" | ||
sse41 -> "-msse4.1" | ||
sse42 -> "-msse4.2" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that there's a pull request that removes explicit (but unused) support for SSE 4.2. This will likely cause issues on master. Please rebase your patch onto master once the linked PR is merged and simply remove this line.
This is awaiting approval by @randombit |
Both x86_32 and x86_64 build using the appropriate toolchain from VS2022, all tests pass except for the following in both cases: