#"Hello World" with `zig c++` fails due to --dependency-file

1 messages · Page 1 of 1 (latest)

shadow imp
#

Hi. I primarily program in C++ for embedded development, and I saw that Zig offers easy cross-compilation for C/C++.

I tried it out and it worked great, but suddenly I'm no longer able to build. I've undone all my changes and even gone down to a simple "Hello world" application in C++ that Zig will no longer compile, saying that --dependency-file is an invalid linker flag.

I've seen on the GitHub that this is a known unsupported flag, but I'm very baffled as to why it was working fine for a while, and now this flag is being added to any project I create and compile with zig c++.

I know there's a fix by adding some extra CMake flags, but I'm more interested in understanding the why, because it wasn't happening a few hours ago.

My CMake file is simply:

cmake_minimum_required(VERSION 3.30)
project(test)

set(CMAKE_CXX_STANDARD 17)

add_executable(test main.cpp)

and I am invoking zig through CMake.

I am running on Ubuntu 22.04 LTS, with CMake 4.0.1.

I am not even cross-compiling anymore and the issue still persists. Is there some kind of cache for zig other than in ~/.cache/zig? Interestingly enough, if I install CMake 4.0.1 and this same version of Zig into a Docker Ubuntu 18.04 container, I do not see this issue.

Any info would be appreciated.

sturdy shale
#

I dont know why it happens but since you are able to run it on a clean linux install, that indicates that something is messed up on your part.

But I find it more interesting why you are calling zig from cmake? or why you even use cmake? the zig build system can replace it fully

shadow imp
#

As for something being messed up, that’s what I’m trying to find. I don’t know what could be broken, as I’ve redownloaded zig and cleaned the project out several times with no success.

As for why I use CMake, it’s because it’s already long established in the C/C++ area with many projects integrating support for it already. I’d like to use zig because it makes the cross compilation process much easier, and I don’t have to modify existing build infrastructure to use it. I don’t particularly want to rewrite all of our build scripts and then also have to maintain scripts for third party libraries when they already provide CMake compatibility.

sturdy shale
shadow imp
#

I have not tried that, but that boils down to very similar commands that I'm already using. But I'm not concerned about that too much, because if I add -DCMAKE_CXX_LINKER_DEPFILE_SUPPORTED=FALSE to my command line invocation of CMake, then the project builds successfully.

I'm just interested in knowing why I didn't need this flag a few hours ago. There's obviously some sort of stored configuration somewhere on my computer that's influencing the cmake configuration step, but I was curious if anyone knew what that might be.

#

I've obliterated my build output folder, re-downloaded zig, deleted ~/.cache/zig and tried older versions of CMake, yet there is something lingering that is requiring this flag.

shadow imp
#

Ok it seems I found part of the issue. I was apparently not using CMake 4.0.1 on my host machine earlier, but instead was on 3.30. I found another GitHub issue that says this bug starts appearing in 3.31.1. Still not sure why it’s okay in a docker container where I am for sure using the newest CMake.