-
Notifications
You must be signed in to change notification settings - Fork 5.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Solidity 0.8.18
binaries built with too new version of GLIBC
for support of Ubuntu 20.04.5 LTS on WSL
#13921
Comments
I can reproduce that with docker, so it's not specific to WSL (see below). We switched to building the Linux version on Ubuntu 22.04 in this release. Some time ago we added a mechanism to load Z3 dynamically (#10483) so the binary is no longer completely static and glibc is actually linked dynamically. This appears to be an incompatibility caused by that. We maintain the Still, the main argument in #10483 was that glibc should be compatible way back to 2.14, released in 2011 and it's unlikely to break compatibility again. @ekpyron, did they actually break compatibility now? Installing from our PPAapt install software-properties-common
add-apt-repository ppa:ethereum/ethereum-static
apt install solc Repro with Dockerdocker run -it --rm ubuntu:focal apt update
apt install --assume-yes wget
cd /tmp
wget https://binaries.soliditylang.org/linux-amd64/solc-linux-amd64-v0.8.18+commit.87f61d96
chmod +x solc-linux-amd64-v0.8.18+commit.87f61d96
./solc-linux-amd64-v0.8.18+commit.87f61d96 --version
|
Yes the PPA approach indeed works and is a temporary fix for anyone who wants to quickly install |
After discussing this with @ekpyron - looks like glibc indeed must have broken compatibility, which is a very rare thing. We'll need to discuss whether we want to continue with these not entirely static builds going forward. For the moment, we're going to fix the problem with this particular release by rebuilding on 20.04 and swapping the binaries in the release. |
@cameel thanks a lot for the swift action - yeah this is a really rare scenario and must be analysed in-depth. |
The binary in solc-bin and on the github release page has been replaced (ethereum/solc-bin#129). We also added a note about it in the release blog post |
Would you be able to confirm that the new 0.8.18 binary should have a On solc-select, we are executing checks against sha256 and keccak256. These are mismatched as below:
I executed a manual test on the binary available at the specified path, and I am still getting the old checksum.
|
@0xicingdeath can confirm the same behaviour and actually pinged 5 mins ago @0xalpharush about that lol. You will always run into the following issue: |
It's possible that the old binary is being cached and being sent back when we try to retrieve. I just tried a curl on the most recent binary and I am still getting the old
|
I tried downloading the most recent from the link too, and I'm getting the |
very very weird - some cloudflare/cloudfront issue? |
If I do |
Agreed, I'm getting inconsistent binaries across platforms when I try to curl from that link. |
@pcaversaccio Built a hotfix into solc-select to let you use the most up to date solidity version. Checkout the latest |
cool, will check it out. Btw now my error changed to a 404 error with the current
|
@0xicingdeath I upgraded to |
Hi @0xicingdeath and @pcaversaccio yes, indeed it was a cache problem. We invalided the cache for this binary now. So it should be working. Sorry for that.
|
Interestingly that the CI test for dapptools is failing now in my PR: dapphub/dapptools#969. Using the "older" version it was successful... |
Description
While installing the new Solidity version
0.8.18
(viasolc-select
) on my WSL instance that usesUbuntu 20.04.5 LTS
I ran into the following problem:For
0.8.17
everything works as intended, so I guess the binaries have been built using a too recent version ofGLIBC
that is not yet supported. Not sure how to fix this tbh. FYI, on Windows everything works smoothly.The text was updated successfully, but these errors were encountered: