wasm-opt: unknown option '--no-stack-ir'

[agarny]

Version of emscripten/emsdk:

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.64-git
clang version 19.0.0git
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /opt/homebrew/Cellar/emscripten/3.1.63/libexec/llvm/bin

Failing command line in full:
The following command gets automatically executed by my CMake-build system that uses emcmake and emcc:

/opt/homebrew/Cellar/emscripten/3.1.63/libexec/binaryen/bin/wasm-opt --strip-target-features --post-emscripten -O3 --low-memory-unused --zero-filled-memory --pass-arg=directize-initial-contents-immutable --no-stack-ir src/libopencor.wasm -o src/libopencor.wasm --mvp-features --enable-multivalue --enable-mutable-globals --enable-reference-types --enable-sign-ext

and it results in:

Unknown option '--no-stack-ir'

From a quick search, it looks like the issue got introduced here.

[agarny]

FWIW, I reverted to emscripten 3.1.62 and, sure enough, it's all working fine for me once again.

[sbc100]

It looks like you are trying to mix emscripten version 3.1.64-git with binaryen from 3.1.62. Because that is new option that was added to binaryen recently mixing versions like that won't work.

[agarny]

It looks like you are trying to mix emscripten version 3.1.64-git with binaryen from 3.1.62. Because that is new option that was added to binaryen recently mixing versions like that won't work.

No, 3.1.62 is the version I reverted to and which works for me. I was using version 3.1.63. And, indeed, which emcc returns /opt/homebrew/bin/emcc which redirects to ../Cellar/emscripten/3.1.63/bin/emcc. So, no idea why emcc -v mentions 3.1.64-git, but as far as I can tell everything is from version 3.1.63. Also, note that InstalledDir mentions /opt/homebrew/Cellar/emscripten/3.1.63/libexec/llvm/bin.

[sbc100]

Ah, I see what happened here. I tagged slightly the wrong version in the emscripten repo for 3.1.63.

I accidentally tagged #22228 which updated the changelog instead of #22200 which was actually used to make the official 3.1.63 release.

This means folks downstream like homebrew got slightly the wrong emscripten version. Normally this would not matter but in this case the intervening revisions started using a brand new binaryen flag. Bag luck I guess.. but good that we caught it.

@kripken what do you think we should do here? I could force push the tag to update it? But I'm not sure how that might effect.

[kripken]

Hmm, updating the tag now might be too late for homebrew, if they've already built from the old tag (unless they want to rebuild, but I have no idea if they do such things, or would be interested to even if they do).

But also updating the tag seems low-risk, and might fix other people, so I'd support updating the tag. You can just delete it remotely and then push it again (no need for a force-push, which at least feels riskier to me as I never remember what is being pushed by the git command - sometimes it pushes branches too).

If we agree to do that then let's file a homebrew issue after we update the tag.

Side issue, when we do that, it might make sense to suggest some kind of testing on the homebrew side (testing an optimized build could have caught this).

[sbc100]

I added a comment to the downstream release commit: Homebrew/homebrew-core@ee9351f

[agarny]

Hi @sbc100, may I ask when we can expect 3.1.64 to be released so that Homebrew can also release a new update? Right now, it's breaking our continuous integration (which installs Emscripten from Homebrew) and, apparently, I am not the only one in this situation.

[sbc100]

I'm on vacation for the next 10 days I'm afraid. I think @kripken or @dschuff should be able to make a release before then.

[kripken]

We can try to do one next week, but @agarny can you use the previous version until then?

[agarny]

We can try to do one next week, but @agarny can you use the previous version until then?

I am using 3.1.62 on my development machine (not thanks to Homebrew since they don't provide an easy way to switch to an older version of a formula), but not in my CI. I guess I could use the same "hack" on GitHub Actions where my CI is done, but that would be messy. Anyway, I am happy to wait until next week. Thanks in advance...

[csjh]

For anyone else looking for a workaround, commenting out line 436 in <emscripten>/tools/link.py seems to work

[JohnSmith-132]

Beast. Thanks, that immediately got the build up and running.

  if will_metadce():
    # passes += ['--no-stack-ir']
    pass
  return passes