Skip to content

Commit 1ddb827

Browse files
avrabeavrabe
committed
fix: convert Tauri icons to RGBA format for build compatibility
1 parent 583adba commit 1ddb827

File tree

6 files changed

+165
-1
lines changed

6 files changed

+165
-1
lines changed

‎glsp-tauri/src-tauri/icons/128x128.png‎

-1.55 KB
Loading

‎glsp-tauri/src-tauri/icons/[email protected]‎

-3.29 KB
Loading

‎glsp-tauri/src-tauri/icons/32x32.png‎

-670 Bytes
Loading

‎workspace/adas-wasm-components/.claude/settings.local.json‎

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,9 @@
2828
"Bash(./build-composed.sh:*)",
2929
"mcp__fetch__imageFetch",
3030
"Bash(bazel build:*)",
31-
"Bash(gh issue view:*)"
31+
"Bash(gh issue view:*)",
32+
"Bash(bazel query:*)",
33+
"Bash(bazel config:*)"
3234
],
3335
"deny": []
3436
}

‎workspace/adas-wasm-components/DEBUG_ANALYSIS.md‎

Lines changed: 113 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,113 @@
1+
# Deep Debugging Analysis: WASI SDK Toolchain Issue
2+
3+
## Root Cause Identified ✅
4+
5+
The WASI SDK is properly downloaded and exists, but there's a **path mismatch** between what the rust_toolchain expects and what actually exists in the sandbox.
6+
7+
## Critical Path Analysis
8+
9+
### What the rust_toolchain is trying to execute:
10+
```
11+
external/rules_wasm_component+/toolchains/rules_wasm_component++wasi_sdk+wasi_sdk/bin/ar
12+
```
13+
14+
### What actually exists in the sandbox:
15+
```
16+
external/rules_wasm_component++wasi_sdk+wasi_sdk/bin/ar -> llvm-ar ✅
17+
```
18+
19+
**Issue**: The rust_toolchain includes an extra `/toolchains/` segment in the path that doesn't exist.
20+
21+
## WASI SDK Status: ✅ WORKING
22+
23+
### WASI SDK Download Status:
24+
- ✅ Successfully downloaded to: `/private/var/tmp/_bazel_r/.../external/rules_wasm_component++wasi_sdk+wasi_sdk/`
25+
- ✅ Contains all required tools: `ar`, `llvm-ar`, `clang`, etc.
26+
- ✅ Tools are executable and properly linked
27+
- ✅ Mapped into sandbox correctly
28+
29+
### WASI SDK Configuration in MODULE.bazel.lock:
30+
```json
31+
{
32+
"strategy": "download",
33+
"version": "25",
34+
"url": "",
35+
"wasi_sdk_root": "" // ⚠️ Empty but tools still downloaded
36+
}
37+
```
38+
39+
## Toolchain Configuration Analysis
40+
41+
### rules_wasm_component Toolchain: ✅ CORRECT
42+
```starlark
43+
filegroup(
44+
name = "wasi_sdk_tools",
45+
srcs = ["@@rules_wasm_component++wasi_sdk+wasi_sdk//:ar", ...] // ✅ Correct path
46+
)
47+
```
48+
49+
### rust_toolchain Configuration: ❌ INCORRECT PATH
50+
- The rust_toolchain is somehow referencing a path with `/toolchains/` inserted
51+
- This suggests the rules_rust fork may have incorrect WASI SDK path construction
52+
53+
## Environment Analysis
54+
55+
### Platform Configuration: ✅
56+
- **Host**: macOS ARM64 (darwin_arm64)
57+
- **Target**: wasm32-wasip2
58+
- **Bazel**: 8.3.1 (Modern Bazel 2025)
59+
- **rules_rust**: commit `1945773a` (avrabe/rules_rust fork)
60+
61+
### Sandbox Analysis: ✅
62+
- WASI SDK tools properly mapped into sandbox
63+
- Symlinks correctly created: `ar -> llvm-ar`
64+
- All binaries executable and accessible
65+
66+
### Configuration Files: ✅
67+
- No conflicting `.bazelrc` files
68+
- No legacy `WORKSPACE` files
69+
- Proper MODULE.bazel bzlmod configuration
70+
- No environment variable conflicts
71+
72+
## Comparison with Working Examples
73+
74+
The rules_wasm_component maintainer reports this works in their examples. Key differences likely:
75+
76+
1. **Build target structure**: They may be using different rust_wasm_component_bindgen configurations
77+
2. **Toolchain registration order**: Different sequence of toolchain registrations
78+
3. **Platform constraints**: Different platform/constraint configurations
79+
4. **rules_rust version**: Potentially using a different commit/branch
80+
81+
## Potential Solutions
82+
83+
### Option 1: Path Correction in rules_rust Fork
84+
The avrabe/rules_rust fork needs to fix the WASI SDK path construction to remove the extra `/toolchains/` segment.
85+
86+
### Option 2: Toolchain Reference Update
87+
Update our MODULE.bazel to use a different toolchain registration that matches the expected path format.
88+
89+
### Option 3: Custom Toolchain Override
90+
Create a custom toolchain configuration that corrects the path mismatch.
91+
92+
## Next Steps
93+
94+
1. **Report to rules_rust fork**: The path construction bug needs to be fixed
95+
2. **Test with different commit**: Try a different rules_rust commit that might have the correct path
96+
3. **Custom toolchain**: Implement a workaround with correct paths
97+
98+
## Verification Commands
99+
100+
```bash
101+
# Check WASI SDK exists and is executable
102+
ls -la /private/var/tmp/_bazel_r/.../external/rules_wasm_component++wasi_sdk+wasi_sdk/bin/ar
103+
104+
# Check sandbox mapping
105+
ls -la /private/var/tmp/_bazel_r/.../sandbox/.../external/rules_wasm_component++wasi_sdk+wasi_sdk/bin/ar
106+
107+
# Debug build with sandbox details
108+
bazel build //test/simple:simple_component_release --sandbox_debug --verbose_failures
109+
```
110+
111+
## Conclusion
112+
113+
The issue is **NOT** with WASI SDK download or configuration. The WASI SDK is working perfectly. The issue is a **path construction bug** in the rules_rust fork where it's inserting an extra `/toolchains/` segment that doesn't exist in the actual repository structure.

‎workspace/adas-wasm-components/ISSUE_RULES_RUST.md‎

Lines changed: 49 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,49 @@
1+
# WASI SDK Path Construction Bug in rust_toolchain
2+
3+
## Summary
4+
The rust_toolchain target is constructing incorrect paths to WASI SDK tools, adding an extra `/toolchains/` segment that doesn't exist in the actual repository structure.
5+
6+
## Environment
7+
- **rules_rust**: commit `1945773a` from `avrabe/rules_rust` feature/wasi-p2-support branch
8+
- **Platform**: macOS ARM64
9+
- **Target**: wasm32-wasip2
10+
- **Bazel**: 8.3.1
11+
12+
## Issue Details
13+
14+
### Expected Path:
15+
```
16+
external/rules_wasm_component++wasi_sdk+wasi_sdk/bin/ar
17+
```
18+
*(This path exists and works correctly)*
19+
20+
### Actual Path Being Used by rust_toolchain:
21+
```
22+
external/rules_wasm_component+/toolchains/rules_wasm_component++wasi_sdk+wasi_sdk/bin/ar
23+
```
24+
*(This path does not exist - note the extra `/toolchains/` segment)*
25+
26+
## Error Message
27+
```
28+
src/main/tools/process-wrapper-legacy.cc:80: "execvp(external/rules_wasm_component+/toolchains/rules_wasm_component++wasi_sdk+wasi_sdk/bin/ar, ...)": No such file or directory
29+
```
30+
31+
## Verification
32+
The WASI SDK is properly downloaded and all tools exist:
33+
```bash
34+
$ ls -la /private/var/tmp/_bazel_r/.../external/rules_wasm_component++wasi_sdk+wasi_sdk/bin/
35+
total 768
36+
-rwxr-xr-x 1 r wheel 97816 Dec 12 2024 ar -> llvm-ar ✅
37+
-rwxr-xr-x 1 r wheel 98344 Dec 12 2024 clang ✅
38+
-rwxr-xr-x 1 r wheel 97816 Dec 12 2024 llvm-ar ✅
39+
# ... all tools present and executable
40+
```
41+
42+
## Root Cause
43+
The rust_toolchain target appears to be incorrectly constructing WASI SDK tool paths by inserting `/toolchains/` where it shouldn't exist. This suggests a bug in how the rules_rust fork references external WASI SDK tools.
44+
45+
## Impact
46+
This prevents successful compilation of WebAssembly components using `rust_wasm_component_bindgen` rules, as the final linking step fails when trying to execute the `ar` tool.
47+
48+
## Requested Fix
49+
Please investigate and fix the path construction logic in the rust_toolchain to reference WASI SDK tools using the correct path format without the extra `/toolchains/` segment.

0 commit comments

Comments
 (0)