Fix Linux build for alternative architectures (riscv64, ppc64le, loon… #4
Conversation
…g64) - Add fix script to patch JavaScript files after npm install - Skip postinstall scripts for alternative architectures to avoid unsupported platform errors - Automatically apply fixes for dependencies-generator.js, calculate-deps.js, types.js, install-sysroot.js, and gulpfile.vscode.linux.js - Makes dependency checks optional for architectures without reference lists
- Improve error reporting in dependencies-generator to show missing/extra deps - Add libudev1 to additionalDeps to ensure it's always included - Fixes build failure where libudev1 wasn't detected when sysroot is skipped
- Improve error reporting in dependencies-generator to show missing/extra deps - Add libudev1 to additionalDeps to ensure it's always included - Fixes build failure where libudev1 wasn't detected when sysroot is skipped
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
This is the final PR Bugbot will review for you during this billing cycle
Your free Bugbot reviews will reset on December 18
Details
You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.
To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.
|
|
||
| set -e | ||
|
|
||
| cd vscode || { echo "'vscode' dir not found"; exit 1; } |
There was a problem hiding this comment.
Bug: Fix script fails due to incorrect working directory
The fix-dependencies-generator.sh script attempts cd vscode at line 9, but when called from package_bin.sh at line 177, the current working directory is already inside the vscode directory (since package_bin.sh previously ran cd vscode at line 17). This causes the script to look for a non-existent vscode/vscode/ path, making it fail immediately with "'vscode' dir not found". The error is caught by the || echo "Warning..." fallback, so the build continues but the critical architecture-specific fixes are never applied, defeating the purpose of the entire fix script.
Additional Locations (1)
- Add type assertions for 'grok-2' model name in extensiveModelOptionsFallback - Add type assertions in xAISettings.modelOptionsFallback function - Resolves build errors: 'grok-2' not assignable to model type union
- Add missing 'grok-2' model configuration to xAIModelOptions - Fixes TypeScript compilation error where 'grok-2' was referenced in fallback but not defined - Ensures consistency with defaultModelsOfProvider.xAI list
| if (lower.includes('llama3')) return toFallback(openSourceModelOptions_assumingOAICompat, 'llama3') | ||
| if (lower.includes('llama3.1')) return toFallback(openSourceModelOptions_assumingOAICompat, 'llama3.1') | ||
| if (lower.includes('llama3.2')) return toFallback(openSourceModelOptions_assumingOAICompat, 'llama3.2') | ||
| if (lower.includes('llama3.3')) return toFallback(openSourceModelOptions_assumingOAICompat, 'llama3.3') |
There was a problem hiding this comment.
Bug: Llama model fallback ordering prevents specific matches
The llama3 check on line 576 matches model names like 'llama3.1', 'llama3.2', and 'llama3.3' before the more specific checks on lines 577-579 can run. Since 'llama3.1'.includes('llama3') is true, line 576 returns immediately with the wrong fallback. The more specific checks (llama3.3, llama3.2, llama3.1) need to come before the generic llama3 check.
| if (lower.includes('llama3.2')) return toFallback(openSourceModelOptions_assumingOAICompat, 'llama3.2') | ||
| if (lower.includes('llama3.3')) return toFallback(openSourceModelOptions_assumingOAICompat, 'llama3.3') | ||
| if (lower.includes('llama') || lower.includes('scout')) return toFallback(openSourceModelOptions_assumingOAICompat, 'llama4-scout') | ||
| if (lower.includes('llama') || lower.includes('maverick')) return toFallback(openSourceModelOptions_assumingOAICompat, 'llama4-scout') |
There was a problem hiding this comment.
Bug: Maverick model incorrectly returns llama4-scout fallback
The condition checks for lower.includes('maverick') but returns llama4-scout instead of llama4-maverick. The llama4-maverick option is defined at line 440 and has different model capabilities. This appears to be a copy-paste error from the previous line.
| // Fallback to gpt-4o-mini for legacy 3.5-turbo requests | ||
| fallbackName = 'gpt-4o-mini' | ||
| } | ||
| if (fallbackName) return { modelName: fallbackName, recognizedModelName: fallbackName, ...openAIModelOptions[fallbackName] } |
There was a problem hiding this comment.
Bug: OpenAI fallback overwrites specific model matches
The OpenAI fallback logic uses sequential if statements without else if, allowing later generic matches to overwrite earlier specific ones. For example, when the model name is 'gpt-5.1', line 1041 correctly sets fallbackName = 'gpt-5.1', but then line 1046 (lower.includes('gpt-5')) also matches and overwrites it to 'gpt-5'. The same issue affects 'gpt-5-pro', 'gpt-5-nano', 'gpt-5-mini', and similar model variants.
| for (const modelName_ in modelOptions) { | ||
| const lowercaseModelName_ = modelName_.toLowerCase() | ||
| if (lowercaseModelName === lowercaseModelName_) { | ||
| return { ...modelOptions[modelName], ...overrides, modelName, recognizedModelName: modelName, isUnrecognizedModel: false }; |
There was a problem hiding this comment.
Bug: Case-insensitive lookup uses wrong key for model options
The getModelCapabilities function performs case-insensitive matching by comparing lowercaseModelName with lowercaseModelName_, but then accesses modelOptions[modelName] using the original input parameter instead of modelOptions[modelName_] (the matched key). Since JavaScript object key access is case-sensitive, if a user provides "GPT-4O" but the key in modelOptions is "gpt-4o", the comparison succeeds but modelOptions["GPT-4O"] returns undefined, causing the model capabilities to be lost.
- Add 'rm -rf vscode' before cloning from GitHub - Prevents 'untracked working tree files would be overwritten' error in CI - Matches the behavior of the local repo path which already removes vscode dir - Fixes CI build failure when vscode directory exists with modified files
| # Apply fixes for alternative architectures after npm install | ||
| if [[ "${VSCODE_ARCH}" == "riscv64" ]] || [[ "${VSCODE_ARCH}" == "ppc64le" ]] || [[ "${VSCODE_ARCH}" == "loong64" ]]; then | ||
| echo "Applying fixes for ${VSCODE_ARCH} architecture support..." | ||
| bash "../build/linux/fix-dependencies-generator.sh" || echo "Warning: Fix script failed, continuing..." |
There was a problem hiding this comment.
Bug: Fix script expects wrong working directory and always fails
The fix-dependencies-generator.sh script is called from package_bin.sh when the working directory is already inside vscode/ (as evidenced by the npm ci and node build/... commands operating on relative paths). However, the fix script's first action is cd vscode at line 9, which looks for a nested vscode/vscode/ directory that doesn't exist. This causes the fix script to always fail with "'vscode' dir not found", and the architecture-specific fixes that are the core purpose of this PR are never applied. The error is silently caught by || echo "Warning: Fix script failed, continuing...".
Additional Locations (1)
The package_reh.sh script was setting VSCODE_SYSROOT_PREFIX=-glibc-2.28, but the checksums file expects the full name with GCC version (e.g., -glibc-2.28-gcc-10.5.0). The setup-env.sh script already sets the correct prefix for each sysroot download, so we should not override it in package_reh.sh.
| if (lower.includes('grok-4')) fallbackName = 'grok-4' | ||
| if (lower.includes('grok-2')) fallbackName = 'grok-2' | ||
| if (lower.includes('grok-3')) fallbackName = 'grok-3' | ||
| if (lower.includes('grok')) fallbackName = 'grok-3' |
There was a problem hiding this comment.
Bug: xAI grok fallback overwrites specific model matches
The xAI modelOptionsFallback uses sequential if statements with assignment instead of early returns. The final check lower.includes('grok') at line 1153 matches any grok model (since 'grok-4' and 'grok-2' both contain 'grok'), overwriting the correct earlier match with 'grok-3'. For example, a request for 'grok-4' will incorrectly receive 'grok-3' configuration.
| export const getProviderCapabilities = (providerName: ProviderName) => { | ||
| const { providerReasoningIOSettings } = modelSettingsOfProvider[providerName] | ||
| return { providerReasoningIOSettings } | ||
| } |
There was a problem hiding this comment.
Bug: Missing guard in getProviderCapabilities crashes on invalid provider
The getProviderCapabilities function lacks the guard check that exists in getModelCapabilities for invalid provider names. When an invalid provider (like "auto" or any non-existent provider) is passed, the code attempts to destructure providerReasoningIOSettings from undefined (modelSettingsOfProvider[providerName]), which will throw a runtime error. The getModelCapabilities function at lines 1948-1952 has this guard but it was not added to getProviderCapabilities.
| if (lower.includes('claude-3-5-haiku') || lower.includes('claude-3-5-haiku-latest')) fallbackName = 'claude-3-5-haiku-20241022' | ||
| // Claude 3 models (legacy) | ||
| if (lower.includes('claude-3-opus') || lower.includes('claude-3-opus-latest')) fallbackName = 'claude-3-opus-20240229' | ||
| if (lower.includes('claude-3-sonnet') || lower.includes('claude-3-sonnet-latest')) fallbackName = 'claude-3-sonnet-20240229' |
There was a problem hiding this comment.
Bug: Anthropic fallback patterns overwrite specific model matches
The Anthropic model fallback has the same sequential-if issue. For example, claude-opus-4-5 correctly matches line 813, but line 819's includes('claude-opus-4') also matches because "claude-opus-4" is a substring of "claude-opus-4-5", causing the result to be overwritten to the legacy claude-opus-4-20250514 model instead of the intended claude-opus-4-5-20251101.
…g64)
Note
Enables Linux builds on alternative architectures with dependency-generator and packaging fixes, patches fetch imports, raises Windows menu z-index, adds a model capabilities registry, and improves repo/deps tooling with docs.
riscv64,ppc64le,loong64viabuild/linux/fix-dependencies-generator.shand updates topackage_bin.sh/package_reh.sh(skip postinstall scripts, arch-specific env/mappings).libudev1).build/lib/dependencies.jsto enumerate production deps.get_repo.shto remove existingvscodedir before clone/copy.event-streamusage inbuild/lib/fetch.{ts,js}for Node downloads.vscode/src/vs/workbench/contrib/cortexide/common/modelCapabilities.tsdefining provider/model defaults, fallbacks, and reasoning/tooling capabilities.ISSUES_FOUND_AND_FIXED.mdandLINUX_BUILD_FIX_SUMMARY.mdsummarizing fixes and Linux migration notes.Written by Cursor Bugbot for commit bf29462. This will update automatically on new commits. Configure here.