sarman/tftsr-devops_investigation
1
1
Fork 0
Code Issues 4 Pull Requests Actions 34 Packages Projects 3 Releases 6 Wiki Activity
149f170435
tftsr-devops_investigation/BUILD_FIX_SUMMARY.md
Shaun Arman 7316339ae2
Some checks failed
Release Beta / autotag (push) Successful in 39s
Details
Release Beta / changelog (push) Successful in 1m26s
Details
Test / frontend-tests (push) Successful in 1m55s
Details
Test / frontend-typecheck (push) Successful in 2m8s
Details
Release Beta / build-macos-arm64 (push) Successful in 4m8s
Details
Release Beta / build-linux-amd64 (push) Failing after 4m39s
Details
Release Beta / build-windows-amd64 (push) Failing after 4m52s
Details
Release Beta / build-linux-arm64 (push) Failing after 5m22s
Details
Test / rust-clippy (push) Has been cancelled
Details
Test / rust-tests (push) Has been cancelled
Details
Test / rust-fmt-check (push) Has been cancelled
Details
fix(ci): resolve libsodium pkg-config detection across all platforms 
## Problem
All three CI build platforms (linux-amd64, windows-amd64, linux-arm64)
were failing with libsodium detection errors in release-beta.yml:
- Linux: "libsodium not found via pkg-config or vcpkg"
- Windows: "SODIUM_LIB_DIR is incompatible with SODIUM_USE_PKG_CONFIG"

## Root Cause
The libsodium-sys-stable crate requires explicit environment configuration:
- Linux needs SODIUM_USE_PKG_CONFIG=1 to find libsodium-dev packages
- Windows needs SODIUM_LIB_DIR pointing to pre-built libs OR pkg-config (not both)
- Cross-compilation requires complete PKG_CONFIG_PATH for arch-specific .pc files

## Solution

### release-beta.yml fixes:
1. **linux-amd64**: Added SODIUM_USE_PKG_CONFIG=1
2. **windows-amd64**:
   - Set SODIUM_LIB_DIR=/usr/x86_64-w64-mingw32/lib (was "")
   - Added SODIUM_USE_PKG_CONFIG=no (explicit disable)
   - Standardized SODIUM_STATIC=1 (was "yes")
3. **linux-arm64**:
   - Added SODIUM_USE_PKG_CONFIG=1
   - Extended PKG_CONFIG_PATH to include /usr/aarch64-linux-gnu/lib/pkgconfig

### auto-tag.yml fixes:
- **linux-arm64**: Extended PKG_CONFIG_PATH (same as release-beta.yml)

## Additional Fix
Fixed flaky test `shell::pty::tests::test_is_alive` by adding retry logic
for process reaping to handle OS timing variations (macOS was timing out).

## Validation
✅ Local build: cargo check passed
✅ Rust tests: 416 passed, 6 ignored
✅ Frontend tests: 386 passed (45 files)
✅ Linting: cargo clippy + eslint passed
⏳ CI validation: pending push to beta branch

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-06-14 04:36:44 -05:00

2.5 KiB
Raw Blame History

Windows Build Fix Summary

Issue

Windows build was failing with linker error:

undefined reference to `memset_explicit'

This was caused by libsodium-sys-stable (used by tauri-plugin-stronghold) requiring memset_explicit, which is not available in older MinGW toolchains.

Root Cause

  • tauri-plugin-stronghold → stronghold_engine → libsodium-sys-stable v1.24.0
  • libsodium uses memset_explicit for secure memory clearing
  • MinGW doesn't provide memset_explicit in its standard library
  • The function is only available in Windows 8+ SDK with specific headers

Solution

Created a C shim (memset_s_shim.c) that provides memset_explicit implementation:

  • Uses volatile pointers to prevent compiler optimization of memory clearing
  • Falls back to memset_s if Windows 8+ headers are available
  • Compiled only for Windows GNU targets via build.rs

Changes Made

Files Added

  • src-tauri/memset_s_shim.c - C implementation of memset_explicit fallback

Files Modified

  • src-tauri/build.rs

    • Added conditional compilation of shim for Windows GNU targets
    • Uses cc crate to compile C code

  • src-tauri/Cargo.toml

    • Added cc = "1.0" to [build-dependencies]

  • .gitea/workflows/release-beta.yml

    • Set CFLAGS_x86_64_pc_windows_gnu: "-D_WIN32_WINNT=0x0602" (Windows 8)
    • Set SODIUM_STATIC: "yes" to force static linking
    • Set SODIUM_LIB_DIR: "" to use vendored build

Technical Details

The C Shim

void *memset_explicit(void *s, int c, size_t n) {
    volatile unsigned char *p = (volatile unsigned char *)s;
    while (n--) {
        *p++ = (unsigned char)c;
    }
    return s;
}

The volatile keyword prevents the compiler from optimizing away the memory write operations, which is crucial for security-sensitive memory clearing (like clearing crypto keys).

Build Process

  1. build.rs detects Windows GNU target
  2. Compiles memset_s_shim.c using cc::Build
  3. Links the shim object into the final binary
  4. libsodium finds the symbol at link time

Commit

9e3e3766 - fix(build): resolve Windows MinGW memset_explicit linking error

Testing

  • ✅ macOS build: Compiles successfully (shim not compiled)
  • ⏳ Windows build: Will be tested in CI
  • ⏳ Linux builds: Should not be affected (shim not compiled)

References

  • Issue: Windows cross-compilation failing with memset_explicit undefined
  • libsodium uses memset_explicit for secure memory operations
  • MinGW compatibility issue with Windows 8+ APIs