Skip to content
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

Bad architecture when attempting to install compilers #870

Closed
ghost opened this issue Jul 11, 2022 · 2 comments
Closed

Bad architecture when attempting to install compilers #870

ghost opened this issue Jul 11, 2022 · 2 comments
Labels
category: bug Something isn't working size: 8 pieces Extra challenging, requires research, should be broken up

Comments

@ghost
Copy link

ghost commented Jul 11, 2022

Environment information

  • OS: macOS 12.4
  • Python Version: 3.10.5
  • ape and plugin versions:
$ ape --version
0.3.5.dev5+gdf844d11

$ ape plugins list
Installed Plugins:
  template    0.3.0
  alchemy     0.3.1.dev2+g533e7a1
  solidity    0.3.1
  tokens      0.3.0
  vyper       0.3.0

What went wrong?

The issue lies in the dependencies upstream from ape-solidity and ape-vyper

ApeWorX/py-solc-x#152
vyperlang/vvm#10

When compiling contracts for either type, the plugins will attempt to install the relevant compiler (Solidity/Vyper) if one has not been installed already. It seems both the Vyper and Solidity projects only ship x86 binaries in their releases, and without having Rosetta installed macOS will throw an error when each plugin attempts to validate its compiler installation.

Vyper Example (vvm.install_vyper() is called by ape-vyper):

>>> import vvm
>>> vvm.install_vyper()
Traceback (most recent call last):
  File "/Users/ibis/.pyenv/versions/venv/lib/python3.10/site-packages/vvm/install.py", line 309, in _validate_installation
    installed_version = wrapper._get_vyper_version(binary_path)
  File "/Users/ibis/.pyenv/versions/venv/lib/python3.10/site-packages/vvm/wrapper.py", line 20, in _get_vyper_version
    stdout_data = subprocess.check_output([vyper_binary, "--version"], encoding="utf8")
  File "/Users/ibis/.pyenv/versions/3.10.5/lib/python3.10/subprocess.py", line 420, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/Users/ibis/.pyenv/versions/3.10.5/lib/python3.10/subprocess.py", line 501, in run
    with Popen(*popenargs, **kwargs) as process:
  File "/Users/ibis/.pyenv/versions/3.10.5/lib/python3.10/subprocess.py", line 969, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/Users/ibis/.pyenv/versions/3.10.5/lib/python3.10/subprocess.py", line 1845, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
OSError: [Errno 86] Bad CPU type in executable: PosixPath('/Users/ibis/.vvm/vyper-0.3.3')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/ibis/.pyenv/versions/venv/lib/python3.10/site-packages/vvm/install.py", line 267, in install_vyper
    _validate_installation(version, vvm_binary_path)
  File "/Users/ibis/.pyenv/versions/venv/lib/python3.10/site-packages/vvm/install.py", line 312, in _validate_installation
    raise VyperInstallationError(
vvm.exceptions.VyperInstallationError: Downloaded binary would not execute, or returned unexpected output.

Solidity Example (solcx.install_solc() is called by ape-solidity):

>>> import solcx
>>> solcx.install_solc()
Traceback (most recent call last):
  File "/Users/ibis/Documents/py-solc-x/solcx/install.py", line 633, in _validate_installation
    installed_version = wrapper._get_solc_version(binary_path)
  File "/Users/ibis/Documents/py-solc-x/solcx/wrapper.py", line 17, in _get_solc_version
    stdout_data = subprocess.check_output([str(solc_binary), "--version"], encoding="utf8")
  File "/Users/ibis/.pyenv/versions/3.10.5/lib/python3.10/subprocess.py", line 420, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/Users/ibis/.pyenv/versions/3.10.5/lib/python3.10/subprocess.py", line 501, in run
    with Popen(*popenargs, **kwargs) as process:
  File "/Users/ibis/.pyenv/versions/3.10.5/lib/python3.10/subprocess.py", line 969, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/Users/ibis/.pyenv/versions/3.10.5/lib/python3.10/subprocess.py", line 1845, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
OSError: [Errno 86] Bad CPU type in executable: '/Users/ibis/.solcx/solc-v0.8.15'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/ibis/Documents/py-solc-x/solcx/install.py", line 466, in install_solc
    raise exc
  File "/Users/ibis/Documents/py-solc-x/solcx/install.py", line 459, in install_solc
    _validate_installation(version, solcx_binary_path)
  File "/Users/ibis/Documents/py-solc-x/solcx/install.py", line 636, in _validate_installation
    raise SolcInstallationError(
solcx.exceptions.SolcInstallationError: Downloaded binary would not execute, or returned unexpected output. If this issue persists, you can try to compile from source code using `solcx.compile_solc('0.8.15')`.

How can it be fixed?

As noted in the upstream issues, the releases of both compilers only target x86. If both of these projects released as Universal Binaries it would fix the issue without requiring any code changes

The alternative, as discussed with @fubuloubu and @NotPeopling2day, would be for vvm/solcx to compile the binaries from source rather than install a pre-compiled version. Such functionality could either be added in the upstream vvm/solcx projects, or the behavior for installing/validating compiler binaries could be roped directly into ape-vyper/ape-solidity instead.

@ghost ghost added category: bug Something isn't working size: 8 pieces Extra challenging, requires research, should be broken up labels Jul 11, 2022
@ghost
Copy link
Author

ghost commented Jul 11, 2022

For those running on M1 Macs, it seems that Rosetta should be an installation prerequisite for ape-solidity and ape-vyper, as @NotPeopling2day has an M1 Mac but did not run into these same issues.

If the upstream projects aren't updated for the ARM architecture, installing Rosetta manually should function as a workaround:

$ softwareupdate --install-rosetta

@antazoey
Copy link
Member

antazoey commented Oct 30, 2023

Closing as this is not an issue with Core.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: bug Something isn't working size: 8 pieces Extra challenging, requires research, should be broken up
Projects
None yet
Development

No branches or pull requests

1 participant