set wormhole address in solana binary by patching it, to enable other SVM chains to work with the CLI #658
+61
−16
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
From @kcsongor in commit e43c778
"cli: set wormhole address in solana binary by patching it
The problem: solana binaries contain program addresses embedded into
them. Specifically, NTT includes the address of the Wormhole program
it's linked against. Which Wormhole address to include is controlled via
feature flags in the wormhole-anchor-sdk crate, which supports one of
mainnet, devnet, and localhost. For other SVM chains, like Fogo, we
can't build this binary correctly, because there is no way to tell it
which core address to use.
One solution is to roll out an updated version of the
wormhole-anchor-sdk, which allows setting the Wormhole address via an
environment variable. That is likely the prudent solution, but it will
need to be backported to older NTT versions (in case a Fogo deployer
wants to deploy, say, 3.0.0, instead of the main HEAD).
Another solution, which we adopt in this commit, is simply patching the
binary. In other words: compile the binary with the solana flag, then
replace the solana address with the desired address. This seems to work
just fine, there is no checksum signing on the binaries or anything. It
also makes compilation a bit faster, because we don't need to recompile
anything between different targets.
Not sure if we should keep this, but will do for now."