rog-control-center crashes at startup: --cfg tokio_unstable not committed in repo build config

[rafa57600]

Bug: rog-control-center crashes at startup — console-subscriber panics because --cfg tokio_unstable is not committed anywhere in the repo

Platform: Linux. Reproduced with the official Arch Linux extra package (rog-control-center 6.4.0-2), built from the release tarball.

Behavior

The GUI aborts on every launch (SIGABRT → core dump):

thread 'main' panicked at .../console-subscriber-0.5.0/src/lib.rs:266:9:
task tracing requires Tokio to be built with RUSTFLAGS="--cfg tokio_unstable"!

asusd and the asusctl CLI are unaffected — only the GUI crashes.

Root cause

1. console-subscriber ^0.5.0 is an unconditional workspace dependency (Cargo.toml, 6.4.0 and main).
2. rog-control-center/src/main.rs calls console_subscriber::init() unconditionally (line 100 in 6.4.0, line 94 on main). That function panics if Tokio was not compiled with --cfg tokio_unstable.
3. The required cfg is not committed anywhere in the repo:
   • .cargo/config.toml → only a linker + resolver setting, no rustflags
   • Makefile → cargo build $(ARGS), no RUSTFLAGS
   • distro-packaging/PKGBUILD → make build, no RUSTFLAGS
   • .github/workflows/* → no RUSTFLAGS/tokio_unstable anywhere

So any build of the source tarball without a specially-set RUSTFLAGS env produces a GUI that cannot start — including the project's own release.yml build path, which is how Arch and the OGC repo both build it.

Suggested fix

Commit the flag in .cargo/config.toml so every Cargo build gets it by default:

[build]
rustflags = ["--cfg", "tokio_unstable"]

Implemented in PR #362 and verified locally: rebuilding 6.4.0 with this flag starts the GUI correctly; without it, it crashes at startup.

Alternative considered

• Gate console-subscriber behind a feature that distro builds leave off, or
• Use the non-panicking console_subscriber::Builder API.

Committing the cfg is the simplest robust fix, and matches what the code already requires.

Workaround for users

Build with RUSTFLAGS="--cfg tokio_unstable". On Arch: rebuild the asusctl PKGBUILD with that line added in build(). (This is also how the crash was confirmed and the fix verified.)

[luytan]

Please do not build rogcc with tokio-debug feature

[spooky]

This is still an issue, rogcc crashes on start. Fix may be slop, but the issue is real. @luytan can you please reopen the ticket?

[Ghoul4500]

This is still an issue, rogcc crashes on start. Fix may be slop, but the issue is real. @luytan can you please reopen the ticket?

The issue is on the arch linux extras repository. We have opened the issue there. Using the package built by us and in the ogc pacman repo you will not encounter this issue. Can you try using the ogc pacman repo and let us know if the issue persists?

Refer to readme on this repo for instructions: https://github.com/OpenGamingCollective/ogc-arch-packaging

[spooky]

works ok when using ogc package

[rafa57600]

Correction by the reporter (rafa57600): I previously linked a PR (#362) that added --cfg tokio_unstable to the repo .cargo/config.toml. That PR was correctly rejected — I want to be clear that the maintainers were right and I was wrong about the fix location.

Looking at the actual crate config: console-subscriber is an optional dependency gated behind the rog-control-center tokio-debug feature. A normal build does not enable it and does not crash. The crash only occurs when a distro builds with --all-features, which is what the Arch extra PKGBUILD does (cargo build --frozen --release --all-features). This drags the debug-only tracing feature into a production package.

So the real fix belongs in the Arch packaging repo, not upstream: build rog-control-center with default features + x11 (the desktop GUI backend) and without tokio-debug — exactly the instruction given in this thread ("please do not build rogcc with tokio-debug feature"). Upstream and the ogc pacman repo are unaffected, as confirmed here ("works ok when using ogc package").

I have filed/flagged the Arch-side issue separately. Since this GitHub issue describes upstream as if it were the source of the bug, it can be closed — closing it as intended. Thanks to the maintainers for catching the misdirection.