Interesting, I wonder what’s different about MacStadium’s Mac Minis. Or maybe it’s something about the hypervisor.Sure. I'll also read up on what you've found out thus far later.
Btw, if you have the time and are feeling adventurous, I heard there's a trick you can use to SSH into GitHub Actions' macOS instances for some live debugging. Something like this: https://dev.to/retyui/how-debugging-github-actions-with-ssh-273n(I only read the top of the thread so I might have been repeating some known things and ignoring some later developments. If there's something I should know, please kindly point me to it.)Can repro with `-O3` and `-O2`. `-O1` works fine. As does `-Os -march=native`, which is what I would personally choose. Homebrew strips `-O3` and replaces it with something to that effect, except with an explicit arch, e.g. `nehalam`. The cc shim that does that can be found at `/usr/local/Homebrew/Library/Homebrew/shims/mac/super/cc` (shims for other compilers and stuff can be found in the same folder). That's why the Homebrew build works.
*Aside: You can find the actual compiler invocation at `~/Library/Logs/Homebrew/nnn/01.make.cc` if you install from source with brew: `brew install -s nnn`. It would look like*
clang -pipe -w -Os -march=nehalem -std=c11 -o nnn src/nnn.c -lreadline -lncurses -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk -isystem/usr/local/include -isystem/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers -I/usr/local/opt/readline/include -L/usr/local/opt/readline/lib -L/usr/local/lib -L/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries -Wl,-headerpad_max_install_names
*End of aside.*
Not sure why even `-O2` generates wrong code. Let me know if you want to chase this further, but I probably don't have time for that until the weekend.See my response on zmwangx/rust-ffmpeg: https://github.com/zmwangx/rust-ffmpeg/issues/40#issuecomment-729669609I expect a lot of work supporting wasm as a target when there’s a big C dependency (in fact not just C, there’s C++ too, and even Rust in the form of rav1e). I have little experience in that regard so the work won’t be coming from me. If someone’s willing to take up that work, I’m open to merging it. Anyone who would like to use FFmpeg in a wasm context but don’t want to put in the work might find more success with an existing wasm port of FFmpeg, e.g. https://ffmpegwasm.github.io/.