Create solana-sdk-wasm-js crate #138

LucasSte · 2025-04-11T20:40:47Z

Problem

solana-program and solana-sdk have both cdylib and rlib declared as crate types. Both crates are supposed to be used as libraries by other projects. This setting is specially problematic for SBF programs that import solana-program, since it does not permit us to run link-time optimizations:

   Compiling solana-program v2.2.1
error: lto can only be run for executables, cdylibs and static library outputs

error: could not compile `solana-program` (lib) due to 1 previous error

The problem lies in using cdylib and rlib together, since that prevents Rust from running LTO, when using Solana-program as a dependency. See rust-lang/rust#51009 for more information.

Summary of changes

Since the cdylib and the rlib types are only here to be compatible with the wasm target for wasm-pack, I created a new crate solana-sdk-wasm to hold all the items necessary for such a target.
Use only rlib for crate types in both solana-program and solana-sdk.
Updated the CI jobs accordingly.
Update the comments in program/src/lib.rs to correctly mention how to use the crate types.

Basic benchmark

This is not a comprehensive benchmark. I was just curious on the impact on a small Hello, Solana! program, like this:

entrypoint!(process_instruction);
fn process_instruction(
    _program_id: &Pubkey,
    accounts: &[AccountInfo],
    instruction_data: &[u8],
) -> ProgramResult {
    msg!("Hello, Solana!");
    Ok(())
}

These are the results:

No LTO: 18kb (18504 bytes) with 728 CUs consumed.
LTO enabled: 17kb (17576 bytes) with 638 CUs consumed.

joncinque

The main change introduced in this PR is that people need to run wasm-pack against your new package to get a binary that's usable in JS, and that should be the only breakage.

It's as if solana-sdk had a binary output and a library output (like solana-gossip), but we're just factoring the binary part into a new crate.

This means we can keep all of the code as is, but just re-export functions from the new crate, along with instructions for building. Does that make sense?

program/Cargo.toml

program/src/lib.rs

sdk-wasm/Cargo.toml

sdk/src/lib.rs

sdk/Cargo.toml

sdk-wasm/README.md

LucasSte · 2025-04-29T17:23:53Z

This means we can keep all of the code as is, but just re-export functions from the new crate, along with instructions for building. Does that make sense?

I didn't quite get the idea. Can I still maintain the wasm-specifc code in the new crate, but then re-export it in Solana-program and in solana-sdk? Or is it the opposite?

joncinque · 2025-04-30T21:37:48Z

I didn't quite get the idea. Can I still maintain the wasm-specifc code in the new crate, but then re-export it in Solana-program and in solana-sdk? Or is it the opposite?

Ah, sorry it wasn't clear. The wasm-specific code should still live in the original crate, and the new crate just re-exports everything and can be built into a JS package with wasm-pack.

ilya-bobyr · 2025-05-07T00:13:33Z

Problem

solana-program and solana-sdk have both cdylib and rlib declared as crate types. Both crates are supposed to be used as libraries by other projects. This crate setting is specially problematic for SBF programs that import solana-program, since it does not permit us to run link-time optimizations:
   Compiling solana-program v2.2.1
error: lto can only be run for executables, cdylibs and static library outputs

error: could not compile `solana-program` (lib) due to 1 previous error

Based on the above, it looks like in order to run LTO, you need the solana-program crate marked with cdylib or staticlib(?).
Though, it is unclear if this applies just to the final target type, or also to all the dependencies.
The error says "could not compile solana-program (lib)", so it seems that the dependencies need to be one of the specified types as well.

Summary of changes

1. Since the cdylib and the rlib types are only here to be compatible with the wasm target for wasm-pack, I created a new crate `solana-sdk-wasm` to hold all the items necessary for such a target.

2. Use only rlib for crate types in both `solana-program` and `solana-sdk`.

[...]

And yet, later, you are saying that rlib should be used for solana-program.
And it is in the diff, that lib.crate-type is changed from ["cdylib", "rlib"] to ["rlib"] (https://github.com/anza-xyz/solana-sdk/pull/138/files#diff-3c9d25a189ead32ebcc2ba81fb9b1a6ff81f14631141bbaf1202e0ddf98fe716R129-R131).

You are saying that you do see a size reduction. So, I'm probably missing something.
But I wonder if I am not the only one who might be confused here.

Or is it that the type of the dependent crates does not matter, and only the type of the final artifact matters?
If this is the case, then solana-program crate type should not be affecting the type of the crate that holds a specific program.
But you are narrowing the solana-program crate type.

LucasSte · 2025-05-07T14:45:44Z

@ilya-bobyr The problem is the usage of multiple crate types together. A short answer is that dependencies should be rlib and final objects should be cdylib, executables or staticlibs for LTO to run.

The option RUSTFLAGS= -C lto=fat is applied to all steps of the compilation, including the dependencies, so rustc will try to run LTO to generate the intermediate objects specified in the dependencies. In the case of Solana-program, rustc will generate an .so file for the crate, since it is specified in the crate types on its toml file. While rlib requires all functions to be present (no LTO needed), cdylib only requires the exported ones, so Rust doesn't work when you have two conflicting types of crates (this is a known issue in the compiler: rust-lang/rust#51009).

The plan is to support LTO via cargo-build-sbf, in which case we need the correct configuration of crate types. Since most solana programs depend on our own library, setting it to rlib facilitates it.

program/src/lib.rs

LucasSte · 2025-05-12T21:06:07Z

As per the discussion on Discord (https://discord.com/channels/428295358100013066/476811830145318912/1370445804078235908), I reverted the PR back to its original form. Let me know if there is any other feedback to be addressed.

joncinque

Looks good overall, and will be an important first step to eventually extracting the wasm-bindgen bits out of the component crates.

joncinque · 2025-06-12T11:51:29Z

program/Cargo.toml

@@ -109,10 +109,7 @@ arbitrary = { workspace = true, features = ["derive"] }
 solana-logger = { workspace = true }

 [target.'cfg(target_arch = "wasm32")'.dependencies]
-console_error_panic_hook = { workspace = true }
-console_log = { workspace = true }
 getrandom = { workspace = true, features = ["js", "wasm-bindgen"] }


Is this still needed? I thought we'd only need it in the sdk-wasm-js crate

I did have a problem before with getrandom not being compatible with wasm, since it does not implement the random number generation for wasm unless we explicitly pass on the feature. I wasn't able to replicate the issue right now, so I'll remove the import.

I removed the dependency in dcab021. Changes got eaten up during rebase.

sdk-wasm-js/src/lib.rs

joncinque · 2025-06-12T12:11:31Z

sdk-wasm-js/Cargo.toml

+name = "solana-sdk-wasm-js"
+description = "Solana SDK Wasm JS"
+documentation = "https://docs.rs/solana-sdk-wasm-js"
+version = "2.2.2"


Let's just set this to 1.0.0 to start

Fixed in fa316d5.

joncinque · 2025-06-13T18:03:47Z

sdk/Cargo.toml

@@ -197,7 +195,7 @@ all-features = true
 rustdoc-args = ["--cfg=docsrs"]

 [lib]
-crate-type = ["cdylib", "rlib"]
+crate-type = ["rlib"]


joncinque · 2025-06-13T18:04:30Z

sdk-wasm-js/README.md

+
+More information about Solana is available in the [Solana documentation](https://solana.com/docs).
+
+The [Solana Program Organization](https://github.com/solana-program) provides examples of how to use this crate.


Does it? I can't think of any places where we use the wasm crate 🤔

That was just copy and paste. I removed that in fa316d5.

joncinque

Looks good to me! Just needs to fix the merge conflict, then we can land this

This reverts commit 854b07f.

This reverts commit c66f7d7.

LucasSte · 2025-06-20T18:50:13Z

Looks good to me! Just needs to fix the merge conflict, then we can land this

Thanks! I've just rebased the PR.

joncinque

Great work, thanks!

LucasSte force-pushed the wasm-1 branch 6 times, most recently from a880ac3 to 2e6e1fa Compare April 15, 2025 20:12

LucasSte requested review from joncinque and febo and removed request for joncinque April 15, 2025 20:24

LucasSte marked this pull request as ready for review April 15, 2025 20:24

joncinque reviewed Apr 28, 2025

View reviewed changes

LucasSte force-pushed the wasm-1 branch 7 times, most recently from fbbc3d6 to 99e99ed Compare May 6, 2025 19:03

LucasSte requested a review from joncinque May 6, 2025 19:20

joncinque mentioned this pull request May 9, 2025

build: Add js Cargo feature flag for WASM builds #118

Open

febo reviewed May 9, 2025

View reviewed changes

program/src/lib.rs Outdated Show resolved Hide resolved

febo reviewed May 9, 2025

View reviewed changes

program/src/lib.rs Outdated Show resolved Hide resolved

febo reviewed May 9, 2025

View reviewed changes

program/src/lib.rs Outdated Show resolved Hide resolved

LucasSte force-pushed the wasm-1 branch from d80c06c to b52db02 Compare May 12, 2025 20:35

joncinque reviewed Jun 13, 2025

View reviewed changes

LucasSte force-pushed the wasm-1 branch 4 times, most recently from 3a0749d to c264065 Compare June 16, 2025 18:44

joncinque reviewed Jun 20, 2025

View reviewed changes

LucasSte added 18 commits June 20, 2025 15:25

Create program-wasm crate

bb00387

Bundle everything

ff92059

Rename crate

666e263

Remove cdylib

0f21b19

Do not build sdk-wasm for sbf

56cf714

Add README

ba587b8

Update comments

60c4367

Revert changes in the SDK crate

87493fa

Revert changes in the program crate

cc8365b

Remove rlib from sdk-wasm crate

a8348cf

Update README

6777912

Change crate name

db59a6e

Fix typos and improve description

9a86349

Revert "Revert changes in the program crate"

b56961c

This reverts commit 854b07f.

Revert "Revert changes in the SDK crate"

069d9a1

This reverts commit c66f7d7.

Build docs for wasm

26f497f

Remove dependency, rewrite readme and change version

6299bf7

Fix rebase conflicts

3d44a7e

LucasSte force-pushed the wasm-1 branch from c264065 to 3d44a7e Compare June 20, 2025 18:27

joncinque approved these changes Jun 20, 2025

View reviewed changes

joncinque changed the title ~~Create solana-sdk-wasm crate~~ Create solana-sdk-wasm-js crate Jun 20, 2025

LucasSte merged commit 459e4fd into anza-xyz:master Jun 21, 2025
24 checks passed

LucasSte deleted the wasm-1 branch June 21, 2025 09:52


		More information about Solana is available in the [Solana documentation](https://solana.com/docs).

		The [Solana Program Organization](https://github.com/solana-program) provides examples of how to use this crate.

Create solana-sdk-wasm-js crate #138

Create solana-sdk-wasm-js crate #138

Conversation

LucasSte commented Apr 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joncinque left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

LucasSte commented Apr 29, 2025

Uh oh!

joncinque commented Apr 30, 2025

Uh oh!

ilya-bobyr commented May 7, 2025

Uh oh!

LucasSte commented May 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

LucasSte commented May 12, 2025

Uh oh!

joncinque left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joncinque left a comment

Choose a reason for hiding this comment

Uh oh!

LucasSte commented Jun 20, 2025

Uh oh!

joncinque left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

LucasSte commented Apr 11, 2025 •

edited

Loading

LucasSte commented May 7, 2025 •

edited

Loading