Skip to content

Conversation

@mazunki
Copy link
Contributor

@mazunki mazunki commented Oct 14, 2025

nixpkgs/pkgs/build-support/cc-wrapper/add-clang-cc-cflags-before.sh has a flag to suppress the rather annoying (albeit correct) warning:

Warning: supplying the --target x86_64-pc-linux-elf != x86_64-unknown-linux-musl argument to a nix-wrapped compiler may not work correctly - cc-wrapper is currently not designed with multi-target compilers in mind. You may want to use an un-wrapped compiler instead.

This adds an option (enabled by default across the board) to suppress this. Because of how example/ is built, I had to implement it two places (ideally I'd inherit it in example.nix, which is only used as a test currently... maybe we should change that).

@mazunki mazunki changed the title disable verbose warning suppress verbose --target mismatch warning Oct 14, 2025
@mazunki mazunki force-pushed the feat-silence-cc-wrapper-warning branch 2 times, most recently from e18d750 to b715934 Compare October 14, 2025 20:45
@mazunki
Copy link
Contributor Author

mazunki commented Oct 14, 2025

To be clear, I don't think it's correct to ignore the warning, and this is meant as a temporary workaround so that one can actually read the output of the compiler until we have a better solution.

All tests are passing.

@alfreb
Copy link
Contributor

alfreb commented Oct 18, 2025

Interesting. Do we know where --target x86_64-pc-linux-elf != x86_64-unknown-linux-musl comes from? I see we're setting ${ARCH}-pc-linux-elf multiple places - should that be x86_64-unknown-linux-musl instead? See e.g. :

cmake/includeos.cmake:set(TRIPLE "${ARCH}-pc-linux-elf")
cmake/library.cmake:set(TRIPLE "${ARCH}-pc-linux-elf")

@mazunki
Copy link
Contributor Author

mazunki commented Oct 18, 2025

I don't know the answer, but some interesting things to look at are:

$ git clone [email protected]:llvm/llvm-project && cd llvm-project
$ grep -rn -- '-elf' include/ lib/
$ grep -rn -- '-elf' test/ unittests/
$ git clone https://git.savannah.gnu.org/git/config.git && cd config
$ grep -rn -- '-elf'

@mazunki
Copy link
Contributor Author

mazunki commented Oct 18, 2025

The warning itself comes from cc-wrapper, which I'm quite confident is calling our patched llvmPackages/clang++. Because clang++ was built for one target, and IncludeOS & unikernels are being built for another, the cc-wrapper freaks out.

I wonder how this behaves on aarch64. Any knowledge on that @elstr-512?

@mazunki
Copy link
Contributor Author

mazunki commented Oct 18, 2025

While looking into some llvmPackages_19 warnings I stumbled across this: llvm/llvm-project#150147 (comment). Could there be a relationship here?

If we need PIE (do we?), -static-pie seems to be preferred for aarch64.

@MagnusS
Copy link
Member

MagnusS commented Oct 27, 2025

For reference, this is where the warning is coming from: https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/cc-wrapper/add-clang-cc-cflags-before.sh#L29

@mazunki this unfortunately has a conflict now after #2316

@mazunki
Copy link
Contributor Author

mazunki commented Oct 27, 2025

Thanks. Do you know if there's a place where I can filter for conflicts on Github so they're quicker to spot, or perhaps subscribe to them?

The conflict actually makes the implementation for this a bit nicer: we won't need a different implementation for the tests.

@mazunki mazunki force-pushed the feat-silence-cc-wrapper-warning branch from b715934 to e643caf Compare October 27, 2025 21:54
@mazunki
Copy link
Contributor Author

mazunki commented Oct 27, 2025

Fixed and tested. @MagnusS

Copy link
Member

@MagnusS MagnusS left a comment

Choose a reason for hiding this comment

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

I think it's fine to suppress this warning for now as we've relied on this functionality for a while. The warning appeared when we upgraded to 25.05. In the longer term we should consider changing the build to avoid this though -- it would be useful with an issue to track this

@mazunki
Copy link
Contributor Author

mazunki commented Oct 27, 2025

Agreed. I can open one.

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