We are about to change CryticCompile to add the support for multiple compilation units (https://github.com/crytic/crytic-compile/pull/167). The reason is that it's a feature that we are seeing more and more in hardhat projects.
def _extract_bin_obj(self, com: CryticCompile):
ret = []
for compilation_unit in com.compilation_units.values():
ret += [
(
compilation_unit.contracts_filenames[name].absolute + ":" + name,
compilation_unit.bytecode_runtime(name),
)
for name in compilation_unit.contracts_names
if compilation_unit.bytecode_runtime(name)
]
return ret
However, the way oyente deals with libraries is fragile and won't work well here (additionally it only works with direct solc compilation, and won't work with truffle/hardhat etc). I would recommend giving the libraries to bytecode_runtime, which can take an optional libraries parameter: a dictionary from name to address, and let crytic-compile patch the bytecode with the librairies' addresses.
Hi,
We are about to change
CryticCompile
to add the support for multiple compilation units (https://github.com/crytic/crytic-compile/pull/167). The reason is that it's a feature that we are seeing more and more in hardhat projects.As a result, this will not work with the next crytic-compile release: https://github.com/enzymefinance/oyente/blob/69dc0a905d37ae27e9055ccae930e30752b398fb/oyente/input_helper.py#L111-L127
_extract_bin_obj
can be replaced byHowever, the way oyente deals with libraries is fragile and won't work well here (additionally it only works with direct solc compilation, and won't work with truffle/hardhat etc). I would recommend giving the libraries to
bytecode_runtime
, which can take an optionallibraries
parameter: a dictionary from name to address, and let crytic-compile patch the bytecode with the librairies' addresses.