solidity icon indicating copy to clipboard operation
solidity copied to clipboard

CI run with minimum versions of dependencies

Open cameel opened this issue 1 year ago • 3 comments

Currently we only consistently test the code with one set of dependency versions on each platform. It's usually either the latest one of the one installed by default. If we use anything else, it's coincidental - when a different version happens to come with some non-standard CI image.

As pointed out in https://github.com/ethereum/solidity/issues/15117#issuecomment-2120479550, we should really have a CI run with the minimum supported versions to detect breakage. In most cases this breakage is harmless, because it only results in a failure to build, but there have been cases of semantic changes in Boost that resulted in the compiler producing different output (e.g. https://github.com/boostorg/multiprecision/issues/129 or all the various changes to boost::filesystem that affect import processing). Nowadays these will often be caught by tests, but to catch them, have to run them in the first place.

I think it would be enough to have such a run on Linux, as we support the widest range of versions, so it should catch vast majority of problems of this kind.

cameel avatar May 23 '24 14:05 cameel

Hi @cameel,

Is there a table or resource I can reference for what the minimal required OS version is to run solc on each platform?

This would be useful for Foundry so we can keep our minimal build targets in sync.

Related: https://github.com/foundry-rs/foundry/issues/7253

Edit: I did find https://docs.soliditylang.org/en/v0.8.24/installing-solidity.html#prerequisites-all-operating-systems but it does not list the minimal OS version

zerosnacks avatar Jul 11 '24 12:07 zerosnacks

@zerosnacks Not really, we don't target specific OS versions, it's implicit in whether they provide the necessary dependencies. And even then it's mostly about building the compiler. At runtime the static binaries should work pretty much anywhere. Well, the ones we build ourselves and distribute are not always completely static (e.g. Linux ones dynamically link to Z3, which will not work with a very old glibc), then emscripten build is the fallback.

cameel avatar Jul 13 '24 10:07 cameel

This issue has been marked as stale due to inactivity for the last 90 days. It will be automatically closed in 7 days.

github-actions[bot] avatar Oct 11 '24 12:10 github-actions[bot]