0.6.1: build spl-token and spl-associated-token-account without entrypoints

[mikemaccana]

Summary

kite depends on spl-token 9 and spl-associated-token-account 8 without their no-entrypoint feature, so each defines an entrypoint symbol. A test binary that links kite and an Anchor program then has two entrypoints and fails to link:

rust-lld: error: duplicate symbol: entrypoint
>>> defined at solana-program-entrypoint-3.1.1/src/lib.rs:129
>>>            spl_token-….rlib
>>> defined at solana-program-entrypoint-3.1.1/src/lib.rs:129
>>>            libcnft_vault.rlib

Anchor's IDL build links the program's tests, so anchor build failed for compression/cnft-vault in quicknode/solana-program-examples#198. Whether a given program hits it depends on which object files the linker pulls in, so any program's tests can break this way when kite is a dev-dependency.

kite only calls these crates' instruction builders, and the token programs themselves run inside LiteSVM, so neither entrypoint is ever used.

Changes

• Cargo.toml: spl-token and spl-associated-token-account are built with features = ["no-entrypoint"], with a comment saying why.
• Version 0.6.1, with a CHANGELOG entry. Its date is "Unreleased"; set it when you publish.

Testing

• cargo test: 2 unit, 30 integration and 26 doc tests pass.
• nm on the built libraries: before, libspl_token and libspl_associated_token_account each defined entrypoint (T entrypoint). After, neither does.
• In solana-program-examples, turning on the same feature from cnft-vault's test manifest (Cargo unifies features) fixed its anchor build in CI. That workaround, in the three compression examples, can go once 0.6.1 is published.

🤖 Generated with Claude Code

https://claude.ai/code/session_014EotgxjmAGtATDFVnBtjXj

---

Generated by Claude Code