OK last thing, the windows tests fail. But it never set WASM_CC on windows. I am trying unset CC
and if that doens't work, I will just do CC=clang
, and then it will work.
(The problem is that CC=cc
in the windows env, so CC ?= clang
didn't kick in whereas WASM_CC ?= clang
did.
Error: Invalid environment variable format 'unset CC'
OK so plan B, will push again in a few second.
/me gives Windows a sideways glance
I bet they all had CC=cc
, to begin with, but the others were setting CC
/ WASM_CC
already.
I see the mac error. I am going to check github docs to see if it is just possible to start with a blanket set of env vars
That doesn't appear to exist lol https://stackoverflow.com/questions/70137245/how-to-remove-an-environment-variable-on-github-actions yay ambient authority "just ignore the env vars you don't care about, what's the problem?!"
OK @Dan Gohman one more push
oh you are really fast or I am slow :)
it's running
I don't quite understand your last comment
I thought you had to approve me each time. And I either i was wrong about that, or you are doing it really fast :)
undefinod-symbols.txt
is in the macOS CI. WTF. Bad flash or memory?
I didn't make that typo according to git on my end!
woah... "undefinod" is coming from nowhere?
I'm rerunning that job to see if it was somehow a spurious failure
But that's really bizarre
(also, yes, I was just clicking the button fast :-))
I think this might be the first time in my life I hit some corrupted memory! Unless it was a macOS file system bug.
Looks like it failed again, the same way?
Huh. Well I just pushed a new version tweaking Windows CI a a bit. Curious after the files are modified a bit (just to shuffle things around) we still get this issue.
https://github.com/WebAssembly/wasi-libc/pull/273 I decided to just split up the PR to bisect this bug
(or do something more different to try to avoid this corruption!)
https://github.com/WebAssembly/wasi-libc/pull/274 another one
Last updated: Dec 23 2024 at 12:05 UTC