Kamil Śliwak

I can confirm the problem on 0.4.25, though I'm getting a different stack trace: ``` (node:366095) V8: soljson-v0.4.25+commit.59dbf8f1.js:3 Invalid asm.js: Invalid member of stdlib at Object.compileFunction (node:vm:352:18) at wrapSafe (node:internal/modules/cjs/loader:1025:15)...

More binaries might be affected by this: [(Invalid asm.js: Invalid member of stdlib) while trying to compile solidity 0.4.17](https://stackoverflow.com/questions/70364121/invalid-asm-js-invalid-member-of-stdlib-while-trying-to-compile-solidity-0-4).

Thanks for the report! Honestly, I'm not sure what to do about this issue. It looks more like a node.js issue, especially given that these binaries used to work. I...

@cds-amal Also, any reason you're still using the asm.js binaries? We have equivalent wasm builds and these should really be preferred since they're also faster. This issue is pretty low...

See https://github.com/trufflesuite/truffle/issues/4425 Basically, if you use https://binaries.soliditylang.org/emscripten-wasm32/ you'll get only wasm binaries. You can use https://binaries.soliditylang.org/emscripten-asmjs/ as a fallback. If you want to detect the wasm ones on your own,...

Did #410 fix this? Or is there still something to do?

Rebased on `develop`, fixed conflicts.

I mistakenly deleted the wrong branch and github closed it. Reopened.

If you want to see the benchmark diff for this PR you should rebase on `develop` again. I just merged #13097 to fix the `c_ext_benchmark` job. Without the fix there's...

We talked about this on today's call but did not make a decision yet. It's at least clear that we do not want this to be a sudden change that...