Replies: 6 comments 4 replies
|
好吧,原因是Node v26会无视编译工具自动添加Clang LTO参数,去除便可。 $env:npm_config_enable_thin_lto = "false"
$env:npm_config_enable_lto = "false" |
|
(emm,开启后依然无法正常工作,主要问题为“无法读取先前的历史消息”与“无法发送请求”,并且后端经常卡死。还是等待更新吧。) |
|
我也 |
|
以后更新rc就行,alpha bug有点多 |
|
这里不建议把关闭 LTO 的两个环境变量当成最终修复。按你使用的固定版本 dsh-v0.1.3-alpha.1,有两个关键的版本差异:
所以当前证据最充分的 Windows 源码运行基线是 Node 24 + pnpm 11.7.0。建议先在同一 tag 上排除工具链变量: 在仓库目录执行时,corepack pnpm --version 应输出 11.7.0。切换 Node major 后使用 --force,是为了重建 fs-ext、koffi、node-pty 等原生依赖;不要使用 --ignore-scripts。 源码还揭示了一个实际的 Windows 可移植性缺口:fs-ext 被声明为必须编译的依赖,并且在模块顶层导入;但 session lease 的 Windows 分支实际走 acquireLockHandleWin32(),只有 POSIX 分支调用 flock()。因此 Windows 仍被迫编译一个运行路径不使用的 POSIX addon。长期修复更适合按平台延迟加载或调整条件依赖,而不是让 Windows 用户永久关闭 LTO。 如果 Node 24 + pnpm 11.7.0 下安装与 build 通过,但仍然无法读取历史或发送请求,那就是第二个运行期问题,不能继续归到本次 node-gyp 失败。请分别贴出:
这样可以把原生 addon 安装问题与 session/API 运行问题拆开定位。 源码依据:版本与工具链约束、fs-ext 构建许可、Windows 与 POSIX lease 分支、Node 26 Ubuntu lane 与 Windows Node 24 lanes. |

Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
最新
0.1.3-alpha.1于pnpm install构建node-gyp时会失败:若不使用
HTTPS_PROXY环境变量,则:All reactions