Missing libraries is blank

[PatrickAlphaC]

Component

Forge

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

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.0.2 (a7196c2 2024-05-09T00:24:42.563510000Z)

What command(s) is the bug in?

forge build

Operating System

macOS (Intel)

Describe the bug

I have a library that my contracts use as a dependency.

library HuffDeployer {

When I compile this, I get:

Error: 
Failed to compile with zksolc: Missing libraries detected [ZkMissingLibrary { contract_name: "HuffDeployer", contract_path: "lib/foundry-huff/src/HuffDeployer.sol", missing_libraries: [] }]

Run the following command in order to deploy the missing libraries:
forge create --deploy-missing-libraries --private-key <PRIVATE_KEY> --rpc-url <RPC_URL> --chain <CHAIN_ID> --zksync

But in my missing_library_dependencies.json I have this:

[
  {
    "contract_name": "HuffDeployer",
    "contract_path": "lib/foundry-huff/src/HuffDeployer.sol",
    "missing_libraries": []
  }
]

Why is the missing_libraries empty? Even for testing locally do I have to deploy the library?

[dutterbutter]

@PatrickAlphaC yes, you have to deploy all libraries even for testing locally as this is imposed by the compiler. You can refer to the docs on compiling non-inlinable libraries here.

If you have suggestions on how to improve the process of detecting, and informing the user to deploy, and re-compiling please comment accordingly.

[dutterbutter]

Re-opening as this seems to disrupt the experience a lot. Will investigate a solution.

[Karrq]

The empty missing_libraries here is because those would be HuffDeployer's libraries.

In this case, HuffDeployer itself is the missing library, and it has no further libraries. Altough the source is present, this is a non-inlineable library, thus it needs to be deployed on chain for the compilation to succeed.

Note that you might stumble upon #382 in that case, and for now I recommend switching to a script instead of a test (as described in my reply to that issue).

If you have further questions on running the script let's move the conversation to the other issue, and if you feel that you received a proper answer to your issue, you can go ahead and close it. Thanks!

[nbaztec]

@PatrickAlphaC Also the missing libraries file we expect is .zksolc-libraries-cache/missing_library_dependencies.json. There's currently no way to reconfigure it. Could you verify that as well please?

[PatrickAlphaC]

Could you verify that as well please?

Verify what? That I cannot reconfigure this file?

Seems like the TL;DR is that we cannot run scripts inside of tests as such. I'd like to keep this open, as this is very annoying and means I have to make a different development environment for zkSync. I don't think that's the developer experience we are looking for.

[nbaztec]

Seems like the TL;DR is that we cannot run scripts inside of tests as such. I'd like to keep this open, as this is very annoying and means I have to make a different development environment for zkSync. I don't think that's the developer experience we are looking for.

That's the current alpha status of the project. Bridging EVM and zkEVM is a non-trivial undertaking, which becomes even more complex when edge cases such as using cheatcodes within deployed contracts (or plain using foundry context) are considered. Majority of foundry's features rely on EVM execution/opcodes and are not directly applicable to zkSync, thereby needing to be be reimplemented for zkEVM - which is quite resource intensive and a highly moving target. This was already attempted previously and took significant effort to re-invent only a subset of foundry's cheatcodes.

As such, especially to speed track foundry integration in zkSync, we came up with an alternate strategy that gives us majority of foundry's built-in features and cheatcodes without having to re-implement all of them. This has enabled a vast number of use cases that our users can already work with. There were obviously certain trade-offs that had to be made, and this was a known one - the inability to use cheatcodes, or access foundry scope from within deployed contracts.

Certainly there are use-cases that we are willing to consider if they are prevalent, but implementing isolated cases would currently take much resources away from ensuring the soundness of core foundry functionality in the usual scenario, causing a worse user experience for everyone. But as stated, if this is a common scenario, we're happy to consider and prioritize it accordingly.

On the topic of maintaining different development environments for zkSync, this is something that cannot be totally avoided, especially considering the following point of differences:

• Reserve address space < 65536
• 32-byte word size for all bytecodes
• Difference in create2 derived addresses

This would certainly require the existing test suites to be adapted, as has been done by the aave team.

[Karrq]

The discussion has veered away from the original issue, which, as described earlier, seems to have been a non-issue.

[hedgar2017]

@dutterbutter @Karrq we're currently migrating to new LLVM-based assembler and linker, where it will be possible to implement post-compile-time linking the devs are looking for.