Fix compiler family detection issue with clang-cl on macOS

[NobodyXu]

Fixed #1327

[NobodyXu]

I can't know for sure if the compiler is clang-cl, so can't apply the workaround reliably.

Alternatively, we could combine cfg(macos) with accept cl flags check.

if both are true then it's likely clang-cl on macOS, which needs workaroud.

[madsmtm]

It is not clear to me why we even support clang-cl on macOS and Linux? cl.exe is not something you'd run on those platforms, so why would you ever run clang-cl? (Not a blocker for fixing this, just something I'd like to understand ;) )

cfg(macos)

That's a bad idea IMO, since this problem is also present on Linux and Windows hosts, just less prominently since their root paths usually start with a lowercase letter (on Linux), or prefixed with the drive letter (on Windows), but that's not a requirement!

Actually, the -- separator seems to be supported by normal Clang too, so why don't we just do this workaround everywhere?

This would also avoid issues if the user did e.g. .file("-l").

[NobodyXu]

It is not clear to me why we even support clang-cl on macOS and Linux? cl.exe is not something you'd run on those platforms, so why would you ever run clang-cl?

Based on the original issue, I believe they are using cargo-xwin to cross compile to msvc windows from a unix environment.

Actually, the -- separator seems to be supported by normal Clang too, so why don't we just do this workaround everywhere?

Does gcc and other compiler support it?

If they mostly do, we can add -- to compiler detection.

This would also avoid issues if the user did e.g. .file("-l").

Good idea

[madsmtm]

Does gcc and other compiler support it?

$ touch foo.c
$ clang -c -- foo.c
$ gcc -c -- foo.c
gcc: error: unrecognized command-line option '--'

Doesn't seem like it?

[madsmtm]

This... Seems brittle :/.

Not that I have a better solution (yet).

[NobodyXu]

I don't like it either, but I really can't think of an alternative solution that is better

[madsmtm]

What does CMake do? (if we're already following in their footsteps)

[NobodyXu]

Not sure , I didn't check about cmake.

I did remember the -? solution is copied from it, so perhaps it uses that as a hint?

[madsmtm]

I don't feel I know enough to really gauge whether this is the right approach or not, so I'll leave that up to you.

I don't think GitHub allows me to make a neutral review after having requested changes, so just so that won't block you, I've approved it.

[NobodyXu]

Thanks, let me merge it and try shipping it, if it doesn't work we have to revert and find another solution

[messense]

Unfortunately it seems to broke cargo-zigbuild badly: https://github.com/rust-cross/cargo-zigbuild/actions/runs/12723439506/job/35468553100

error occurred in cc-rs: Command LC_ALL="C" "/home/runner/.cache/cargo-zigbuild/0.19.7/zigcc-aarch64-unknown-linux-gnu-6363.sh" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-gdwarf-4" "-fno-omit-frame-pointer" "--target=aarch64-unknown-linux-gnu" "-I" "zstd/lib/" "-I" "zstd/lib/common" "-I" "zstd/lib/legacy" "-fvisibility=hidden" "-DZSTD_LIB_DEPRECATED=0" "-DXXH_PRIVATE_API=" "-DZSTDLIB_VISIBILITY=" "-DZDICTLIB_VISIBILITY=" "-DZSTDERRORLIB_VISIBILITY=" "-DZSTD_LEGACY_SUPPORT=1" "-o" "/home/runner/work/cargo-zigbuild/cargo-zigbuild/tests/zstd-rs/target/aarch64-unknown-linux-gnu/debug/build/zstd-sys-c42cdd11ab2b8d1c/out/7faed3f8272f2313-huf_decompress_amd64.o" "-c" "--" "zstd/lib/decompress/huf_decompress_amd64.S" with args zigcc-aarch64-unknown-linux-gnu-6363.sh did not execute successfully (status code exit status: 1).

[messense]

And it does not seem to resolve the clang-cl issue either:

warning: libz-ng-sys@1.1.16: Compiler family detection failed due to error: ToolExecError: Command "clang-cl" "-E" "/Users/messense/Projects/uv/target/aarch64-pc-windows-msvc/debug/build/libz-ng-sys-e348506bb081d40e/out/442624705732975273detect_compiler_family.c" with args clang-cl did not execute successfully (status code exit status: 1).

[tokatoka]

I think this will break if people uses cc with their own compiler wrappers

For our case, we use a compiler wrapper based on clang and in our wrapper we didn't handle argument -- .
This fix automatically adds "--" automatically, and we had to handle it else it broke.

[NobodyXu]

@messense @tokatoka I've opened #1359, can you try it out please?

[tbetcke]

@NobodyXu I have the same issue with mpicc as compiler wrapper (e.g. used by [rsmpi])(https://github.com/rsmpi/rsmpi). Version 1.2.7 of cc-rs works fine. Version 1.2.8 fails with the -- issue. I have tried #1359. But the error still persists.