Fullstack 0.6.0-alpha.3: (When custom rust flags) Build failed: Failed to parse asset manifest from "/var/folders...

[tgrushka]

Problem

EDIT: Only when custom cargo config/flags/linker.

[dev] Build failed: Failed to parse asset manifest from "/var/folders/...

Steps To Reproduce

EDIT: 0. Have a custom rust config in ~/.cargo/config.toml, i.e.:

[build]
target = "aarch64-apple-darwin"

[target.aarch64-apple-darwin]
linker = "/usr/bin/clang"
rustflags = [
    "-C", "relocation-model=static",
    "-C", "link-arg=--ld-path=/usr/local/bin/ld64.sold"
]

1. cargo install dioxus-cli --force --git 'https://github.com/DioxusLabs/dioxus#main'
2. dx new dx-6-test → fullstack → true → Vanilla
3. cd dx-6-test; dx serve
4. Build almost completes, then above error.

Expected behavior

Expect build to finish and serve. Behaves / serves properly when choosing web instead of fullstack. EDIT: I commented out my ~/.cargo/config.toml and now it builds fine! Would be nice to use faster linker but I see there are other issues about this.

Environment:

• Dioxus version: dioxus 0.6.0-alpha.3 (5d99889)
• Rust version: rustc 1.82.0 (f6e511eec 2024-10-15)
• OS info: macOS 15.0.1 (24A348)
• App platform: fullstack (not an issue on web)

Trace output

...
14:41:45 [dev] Build update: Progress { stage: Compiling { platform: Server, current: 349, total: 351, krate: "dioxus_router" } }
14:41:45 [dev] Build update: Progress { stage: Compiling { platform: Server, current: 350, total: 351, krate: "dioxus" } }
14:41:46 [dev] Build update: BuildFailed { err: Other(Failed to parse asset manifest from "/var/folders/5f/lt49hfxs2f708tdrn5vd31200000gn/T/.tmpU2MG3l"

Caused by:
    EOF while parsing a value at line 1 column 0

Stack backtrace:
   0: std::backtrace::Backtrace::create
   1: anyhow::context::<impl anyhow::Context<T,E> for core::result::Result<T,E>>::with_context
   2: dx::assets::AssetManifest::load_from_file
   3: dx::builder::build::BuildRequest::build_app::{{closure}}
   4: <futures_util::future::try_maybe_done::TryMaybeDone<Fut> as core::future::future::Future>::poll
   5: <futures_util::future::try_join::TryJoin<Fut1,Fut2> as core::future::future::Future>::poll
   6: dx::builder::build::BuildRequest::build_all::{{closure}}
   7: tokio::runtime::task::core::Core<T,S>::poll
   8: tokio::runtime::task::harness::Harness<T,S>::poll
   9: tokio::runtime::scheduler::multi_thread::worker::Context::run_task
  10: tokio::runtime::scheduler::multi_thread::worker::Context::run
  11: tokio::runtime::context::runtime::enter_runtime
  12: tokio::runtime::scheduler::multi_thread::worker::run
  13: <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll
  14: tokio::runtime::task::core::Core<T,S>::poll
  15: tokio::runtime::task::harness::Harness<T,S>::poll
  16: tokio::runtime::blocking::pool::Inner::run
14:41:46 [dev] Build failed: Failed to parse asset manifest from "/var/folders/.../T/.tmpU2MG3l"

[jkelleyrtp]

Hi! We use some special flags to force our own linker to get the incremental artifacts which let us extract out the asset manifest, so it's a known bug that custom linker setups are currently overriding our linker and we can't generate the manifest.

I think, since we migrated to requiring the results of asset!() to actually be used in the final binary, we don't need to intercept the linker anymore, but eventually we do want to do more advanced stuff with the linker which will cause collisions.

All this to say, I don't have a great solution for custom linker setups right now other than disabling them until we start looking for them or getting off of them completely.