forge build fails with solc 0.6.12

[lithp]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (b951f65 2022-03-26T04:46:06.407207863+00:00)

What command(s) is the bug in?

forge build

Operating System

Linux

Describe the bug

When I open a new project but change the solidity version to 0.6.12 forge build fails:

$ forge init forge-2
Initializing $PATH/forge-2...
Installing ds-test in "$PATH/forge-2/lib/ds-test", (url: https://github.com/dapphub/ds-test, tag: None)
    Installed ds-test
    Initialized forge project.
$ cd forge-2
$ forge build
[⠊] Compiling...
[⠢] Compiling 3 files with 0.8.10
Compiler run successful
$ sed -i 's/0.8.10/0.6.12/' src/Contract.sol 
$ grep pragma src/Contract.sol
pragma solidity 0.6.12;
$ forge build
[⠢] Compiling...
Error: 
   0: Solc Error: 

Location:
   cli/src/cmd/utils.rs:40

Backtrace omitted.
Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
$ forge --version
forge 0.2.0 (b951f65 2022-03-26T04:46:06.407207863+00:00)

[gakonst]

Can you do "rm -rf ~/.svm" and try again with "RUST_LOG=ethers forge b" and print the output?

[mattsse]

that's a version from couple days ago,
does this happen with the latest nightly?

could not reproduce with forge 0.2.0 (7aa9f1a 2022-03-29T00:07:15.697736+00:00)
on mac

[onbjerg]

Please try the following (as mentioned above):

rm -rf ~/.svm
foundryup

[lithp]

Confirmed that it happens on the very latest version, forge 0.2.0 (8bcb367 2022-03-29T16:57:35.940754341+00:00), which makes sense because of the following:

---

The problem appears to be happening because I'm running on arm64 linux. I can reproduce the failure by downloading this binary (which has the same sha256 sum as the solc forge installs into ~/.svm):

$ ./solc-v0.6.12 --allow-paths $PATH/forge-2,$PATH/forge-2/lib $PATH/forge-2/src/Contract.sol
Aborted (core dumped)

Currently trying to figure out what's happening, strace makes it look like the binary might be sending SIGABRT to itself.

[lithp]

I was able to build solc from source and the 0.6.12 I built works correctly. When I try to put it into ~/.svm ethers-solc is too smart; it notices the checksum is incorrect (discovered by using RUST_LOG=ethers, thanks for that tip!) and replaces it with the version of solc which aborts :') Is there any way to disable that checksum check?

[onbjerg]

@lithp Yes, running with --offline should skip it :)

[gakonst]

Interesting, is it possible that the builds produced in https://github.com/nikitastupin/solc/ are faulty?

[lithp]

Running it with --offline did the trick, and I'm unblocked, thank you! 🎉

I'm down to help you figure out what if anything is wrong with the arm64 binaries. The binary doesn't appear to be stripped, I'll run it inside gdb and see if anything jumps out at me, but let me know if there are other ways I could help you!

[lithp]

Confusingly, this is the stack trace at abort:

(gdb) bt
#0  0x0000000000cfee08 in gsignal ()
#1  0x0000000000401ac0 in abort ()
#2  0x0000000000ceb114 in uw_init_context_1 ()
#3  0x0000000000ceb674 in _Unwind_RaiseException ()
#4  0x0000000000c4a780 in __cxa_throw ()
#5  0x00000000005a2ea0 in void boost::throw_exception<solidity::langutil::FatalError>(solidity::langutil::FatalError const&) ()
#6  0x0000000000595da8 in void boost::exception_detail::throw_exception_<solidity::langutil::FatalError>(solidity::langutil::FatalError const&, char const*, char const*, int) ()
#7  0x0000000000bc740c in solidity::langutil::ErrorReporter::fatalError(solidity::langutil::ErrorId, solidity::langutil::Error::Type, solidity::langutil::SourceLocation const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#8  0x0000000000bc7584 in solidity::langutil::ErrorReporter::fatalParserError(solidity::langutil::ErrorId, solidity::langutil::SourceLocation const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#9  0x000000000057ee04 in solidity::frontend::Parser::parsePragmaVersion(solidity::langutil::SourceLocation const&, std::vector<solidity::langutil::Token, std::allocator<solidity::langutil::Token> > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) ()
#10 0x000000000057f31c in solidity::frontend::Parser::parsePragmaDirective() ()
#11 0x000000000057e7b4 in solidity::frontend::Parser::parse(std::shared_ptr<solidity::langutil::Scanner> const&) ()
#12 0x0000000000507670 in solidity::frontend::CompilerStack::parse() ()
#13 0x0000000000509400 in solidity::frontend::CompilerStack::parseAndAnalyze() ()
#14 0x00000000005098f4 in solidity::frontend::CompilerStack::compile() ()
#15 0x000000000040ab7c in solidity::frontend::CommandLineInterface::processInput() ()
#16 0x00000000004597c8 in main ()

There's not enough debug info for me to single-step through so I have no idea why the error message would fail to print.

As for why the version check might be failing, I had some trouble getting my locally-built solc to pass the version check, it failed at what appears to be exactly where this stacktrace is failing:

$ ./solc --allow-paths $PATH/forge-2,$PATH/forge-2/lib $PATH/forge-2/src/Contract.sol
Warning: This is a pre-release compiler version, please do not use it in production.

Error: Source file requires different compiler version (current compiler is 0.6.12-develop.2022.3.29+commit.27d51765.Linux.g++) - note that nightly builds are considered to be strictly less than the released version
 --> $PATH/forge-2/src/Contract.sol:2:1:
  |
2 | pragma solidity 0.6.12;
  | ^^^^^^^^^^^^^^^^^^^^^^^

In order to get this check to pass I needed to run touch prerelease.txt before I built solc, that might be part of the problem here?

[gakonst]

Oh that's because you didn't build it with the release flag, see here, you built a pre-release version which ends up not matching the hash

[gakonst]

@nikitastupin any clue on why this core dump might be happening?

[lithp]

Oh that's because you didn't build it with the release flag, see here, you built a pre-release version which ends up not matching the hash

Sorry, I wasn't clear! If I only do the line you linked to then it still builds a pre-release version and fails at the place this stacktrace shows. The built binary only agrees to compile this contract if I also run line 44, touch precompile.txt.

My guess was that these built binaries might not have run line 44. However, it looks like this is the action which built the binaries, so my guess is likely wrong!

[nikitastupin]

Perhaps I've produced the 0.6.12 version with different compiler options because 0.6.12 binary from the nikitastupin/solc is statically linked while it should be dynamically linked.

% file solc-v0.6.12

solc-v0.6.12: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.7.0, BuildID[sha1]=7c6fdc07ff8d037a626ee1724e31b2d5a2a7532c, with debug_info, not stripped

% file solc-v0.8.13

solc-v0.8.13: ELF 64-bit LSB shared object, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=3eb9fd783d7d83fe0505c62d9b42b9160bb27fa2, not stripped

Let me reproduce the issue locally and fix that.

[gakonst]

Ah maybe it was before you had set up the GHA?

[nikitastupin]

Ah maybe it was before you had set up the GHA?

I think that's exactly the case.

Anyways, I've rebuilt and published the solc-v0.6.12 binary but for some reason forge build still downloads the statically linked version 🤔

[onbjerg]

Anyways, I've rebuilt and published the solc-v0.6.12 binary but for some reason forge build still downloads the statically linked version thinking

I think that's because of svm-builds so we probably need to rebuild first

[nikitastupin]

If rebuild solves the problem, I'll update the remaining 30 static binaries 😃

solc $ ls linux/aarch64/* | xargs -n 1 file | grep static | wc -l

      30

[nikitastupin]

Hey @onbjerg,

I think that's because of svm-builds so we probably need to rebuild first

I've just updated forge with foundryup to 475bc10 2022-04-09T00:07:09.434116744+00:00 but the problem is still persists. Is svm-builds already been rebuilt? If no, what can I do to rebuild it?

[mattsse]

believe we have to update links as we're pointing to an outdated commit on svm-rs: https://github.com/roynalnaruto/svm-rs/search?q=nikitastupin

cc @roynalnaruto

[roynalnaruto]

Will update in in a while!

[gakonst]

@lithp this should be fixed now! Could you confirm?

[nikitastupin]

It works for me now. If @lithp confirms the fix, I'll recompile all other [static] binaries and let you know once they're published so we can update one more time. Thank you all for you effort ❤️

[roynalnaruto]

@nikitastupin you can also tag me, so I can update svm-rs once you've pushed new binaries.

[lithp]

Confirmed that with the newest version of forge I no longer need to use the --offline workaround, the downloaded solc just works.

Thank you for the quick help and for the quick resolution! Also, thank you for foundry in general, outside of the little trouble I had here with getting started forge&cast have been immensely helpful, an absolute delight ❤️

[gakonst]

LFG

[nikitastupin]

Hi @roynalnaruto! I've recompiled and published the remaining binaries. Feel free to update svm-rs 😃

[roynalnaruto]

@nikitastupin updating here: alloy-rs/svm-rs#42