Skip to content

Conversation

@yamt
Copy link
Contributor

@yamt yamt commented Jan 13, 2026

No description provided.

@alexcrichton
Copy link
Collaborator

Can you expand more on why you think this should be added? This seems to not work on one version of CMake but works on all others, and it also seems like a useful check. Why disable it everywhere if only one location doesn't work?

@TartanLlama
Copy link

FWIW I need to add this during development for WASIP3 because I don't have a usable libc for the toolchain I'm bootstrapping

@alexcrichton
Copy link
Collaborator

That makes sense to me yeah where the wasm32-wasip3 target doesn't actually exist in any compiler/sysroot/etc. I understand the need for one-off applications of this flag, but I don't feel that it is necessary to unconditionally specify this with no possible override in the in-repo build configuration

@yamt
Copy link
Contributor Author

yamt commented Jan 16, 2026

Can you expand more on why you think this should be added? This seems to not work on one version of CMake but works on all others, and it also seems like a useful check. Why disable it everywhere if only one location doesn't work?

i don't think it's a version of CMake. it's your C toolchain it matters.
as commented in the patch, what CMAKE_C_COMPILER_WORKS checks is beyond our actual requirement.
although it might be useful in some cases, this is not an approprate place to check random useful features, IMO.

@alexcrichton
Copy link
Collaborator

If it's the C toolchain matters, why is this check actively harmful? Why would one older, possibly buggy, toolchain mean that no other toolchain should be verified? You comment saying that CMAKE_C_COMPILER_TARGET isn't set, but why can't it be set?

Why isn't this an appropriate place to check that the compiler works? The documentation you've written says that crt objects aren't needed, but they are indeed needed for linking *.so binaries.

I basically still don't understand why this check should be blanket disabled. I understand the need for 1-off exceptions, but completely disabling it is different and doesn't feel justified to me yet

@yamt
Copy link
Contributor Author

yamt commented Jan 20, 2026

If it's the C toolchain matters, why is this check actively harmful? Why would one older, possibly buggy, toolchain mean that no other toolchain should be verified? You comment saying that CMAKE_C_COMPILER_TARGET isn't set, but why can't it be set?

Why isn't this an appropriate place to check that the compiler works? The documentation you've written says that crt objects aren't needed, but they are indeed needed for linking *.so binaries.

we (wasi-libc) produce crt objects. we should not require the toolchain provide them.

I basically still don't understand why this check should be blanket disabled. I understand the need for 1-off exceptions, but completely disabling it is different and doesn't feel justified to me yet

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.

3 participants