solc-bin issue: one commit for different versions?

[fanatid]

Two files in bin folder with same commit but with different content, is it was error or was made intentionally?

md5sum .soljson/*4457170*
40087b0c6c5772221bf09e76d311fe74  .soljson/soljson-v0.1.3-nightly.2015.9.25+commit.4457170.js
cc36e9b9ff0abf281068b5bdfad707db  .soljson/soljson-v0.1.3-nightly.2015.9.28+commit.4457170.js

Also, few files have stable and nightly builds: 7dab890, 4dc1cb1, 81ae2a7

Why issues is not available in https://github.com/ethereum/solc-bin ?

[chriseth]

This is very old code. My guess would be that the date is part of the version string and thus the binaries are different, but we did not have a very reproducible build system back in the days anyway.

[fanatid]

@chriseth thank you for answer. Can you answer for yet one question: some of the commit hashes have length 6 or 7 symbols, instead 8. Is this related with build system in old days? Right now all versions will have 8 symbols, right?

[axic]

It should be due to the old one. Github uses 7 characters, but I think we've settled on 8 as it is less weird.

[fanatid]

@chriseth @axic sorry for noise here.
It is looks like we can extract 8 symbols from version. Will you accept PR to solc-bin which change all file names with not 8 symbols to 8 symbols or I even can not try do it, because it will not be accepted?

[chriseth]

Note that due to the fact that we are using semver, leading zeros in the commit hash have to be omitted after the + - might that be the reason there are only 7 characters?

[chriseth]

The thing is that the filename should match exactly the string reported by the version function of the binary.

[axic]

The thing is that the filename should match exactly the string reported by the version function of the binary.

It doesn't. We have unified the filenames, before there was the comprehensive list.json.

@fanatid why in the first place do you want to rely on the filenames? list.json should be the best place to consult for information

[fanatid]

Wow, I did not knew that leading zeros in hash is omitted... but I had check:
(result is call of soljson.cwrap('version', 'string', []))
soljson-v0.1.5-nightly.2015.10.16+commit.52eaa47 => 0.1.5-52eaa477/.-Emscripten/clang/int linked to libethereum-
soljson-v0.3.1-nightly.2016.4.7+commit.54bc2a => 0.3.1-054bc2a6/.-Emscripten/clang/Interpreter

I can do bypass in my project (may be you will be interesting btw -- https://github.com/fanatid/ethereum-verified-contracts), but I'd prefer fix hashes in solc-bin.

I also found, that if I compile few different contracts, solc can return wrong bytecode. https://github.com/fanatid/ethereum-verified-contracts/blob/a1caf307292f9a1f10be9e5b0b5556679c5fa1df/bin/verify.js#L180

[fanatid]

@axic I also would like move verified contracts to ethereum organization, I think this will helpful to many devs. We will add CI/UI later.

[fanatid]

Problem with hashes that I parse etherscan and can not find right solc version in solc-bin. I decide use only first 7 symbols, but 54bc2a contains even 6, so was needed add exception here.
I understand that changing files names here can be wrong idea, but I decide ask you first.

[chriseth]

Oh wow that's a great project! Are you using the address or the metadata? Perhaps we should schedule a call. Do you want to come to http://gitter.im/ethereum/solidity-dev to discuss?

[fanatid]

Are you using the address or the metadata?

Sorry, this is not clear, can you elaborate?
I had send message to you in gitter.

[axic]

Btw, somewhat related, here is a semver converter, which supports all irregular ones from the past: https://github.com/ethereum/solc-js/blob/master/translate.js#L3

I've created a PR to insert reportVersion in list.json, but loading each compiler results in running out of memory. Even if I force-run GC. There must be some kind of leak in solc-js or the emscripten compiled code.

[fanatid]

I've created a PR to insert reportVersion in list.json, but loading each compiler results in running out of memory. Even if I force-run GC. There must be some kind of leak in solc-js or the emscripten compiled code.

Yes, this is one of them items why I verify contracts (i.e. load specific solc version) in child process ;)