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

Add support for building with clang-cl #4255

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

solemnwarning
Copy link
Contributor

Both x86_32 and x86_64 build using the appropriate toolchain from VS2022, all tests pass except for the following in both cases:

System Certificate Store - Find Certificate by UTF8 subject DN ran 1 tests in 1.04 msec 1 FAILED
Failure 1: found certificate was nullopt (at src/tests/test_certstor_system.cpp:306)

@coveralls
Copy link

coveralls commented Jul 24, 2024

Coverage Status

coverage: 91.275% (+0.001%) from 91.274%
when pulling cce2b6d on solemnwarning:clang-cl
into 1499274 on randombit:master.

@solemnwarning solemnwarning force-pushed the clang-cl branch 2 times, most recently from 6b32b1e to 630d6f1 Compare July 25, 2024 22:34
@solemnwarning
Copy link
Contributor Author

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.

@reneme
Copy link
Collaborator

reneme commented Jul 27, 2024

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.

Copy link
Collaborator

@reneme reneme left a 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

src/build-data/cc/clangcl.txt Show resolved Hide resolved
@reneme
Copy link
Collaborator

reneme commented Jul 31, 2024

@solemnwarning could you rebase to master and see if the test succeeds on your platform now?

@solemnwarning
Copy link
Contributor Author

@reneme

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 /Zc:preprocessor, it still builds okay, so I assume its fine without?

@reneme
Copy link
Collaborator

reneme commented Aug 1, 2024

Regarding /Zc:preprocessor, it still builds okay, so I assume its fine without?

I added that for a change in the tests. So if the unit tests (make tests) still build fine, I'd also conclude that it's not needed.

they do pass if I import the "D-TRUST Root Class 3 CA 2 EV 2009"

👍

Copy link
Collaborator

@reneme reneme left a 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.

src/lib/math/bigint/big_ops2.cpp Outdated Show resolved Hide resolved
src/build-data/cc/clangcl.txt Outdated Show resolved Hide resolved
src/lib/math/bigint/big_ops2.cpp Show resolved Hide resolved
src/lib/tls/tls13_pqc/hybrid_public_key.h Outdated Show resolved Hide resolved
src/lib/tls/tls13_pqc/hybrid_public_key.cpp Outdated Show resolved Hide resolved
src/lib/tls/tls13_pqc/hybrid_public_key.cpp Outdated Show resolved Hide resolved
@solemnwarning solemnwarning force-pushed the clang-cl branch 2 times, most recently from f3f45bc to 6171bd3 Compare August 5, 2024 18:43
src/lib/prov/pkcs11/p11.h Show resolved Hide resolved
src/lib/utils/socket/socket.cpp Outdated Show resolved Hide resolved
Copy link
Collaborator

@reneme reneme left a 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>
Copy link
Collaborator

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?

Copy link
Owner

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.

@randombit randombit self-requested a review August 13, 2024 10:50
@@ -3,7 +3,7 @@
* configure.py to determine the compilers version number.
*/

#if defined(_MSC_VER)
#if defined(_MSC_VER) and !defined(__clang__)
Copy link
Owner

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__

Copy link
Collaborator

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:

  1. it probably doesn't hurt to handle clang-cl explicitly here,
  2. 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>
Copy link
Owner

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.

src/lib/prov/pkcs11/p11.h Show resolved Hide resolved
@@ -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}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This behavior (passing the compiler flags also to the linker) was just added in #4206 which I guess is kind of inelegant but we'd need to figure out some alternate solution for #4196

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
Copy link
Owner

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?

Copy link
Contributor Author

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.

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.

src/lib/math/bigint/big_ops2.cpp Show resolved Hide resolved
src/lib/math/bigint/big_ops2.cpp Show resolved Hide resolved
@solemnwarning
Copy link
Contributor Author

@randombit @reneme

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"
Copy link
Collaborator

@reneme reneme Sep 2, 2024

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.

@reneme
Copy link
Collaborator

reneme commented Sep 2, 2024

Are either of you anticipating me making any changes on this PR?

This is awaiting approval by @randombit

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.

5 participants