Emscripten动态链接中FETCH标志的符号类型不匹配问题解析

在Emscripten 3.1.64版本中，开发者遇到了一个与动态链接和FETCH功能相关的符号类型不匹配问题。这个问题源于LLVM 19的一个变更，影响了使用-sFETCH标志进行动态链接时的编译过程。

问题现象

当开发者尝试使用-sFETCH标志进行动态链接时，会收到一系列wasm-ld的错误提示，指出多个与fetch相关的符号存在类型不匹配。例如：

wasm-ld: error: symbol类型不匹配: _emscripten_get_fetch_queue
>>> 在libfetch.a中定义为WASM_SYMBOL_TYPE_DATA类型
>>> 在Qt6Qml.so中定义为WASM_SYMBOL_TYPE_FUNCTION类型

类似的问题还出现在emscripten_proxy_fetch和emscripten_fetch_attr_init等符号上。

问题根源

经过分析，这个问题与LLVM 19的一个特定变更有关。该变更影响了符号类型的处理方式，导致在动态链接场景下，同一个符号在不同模块中被赋予了不同的类型定义。

解决方案

开发者发现，问题的根本原因在于构建系统中对-sFETCH标志的使用方式。在项目中，该标志被同时传递给了主模块(MAIN_MODULE)和侧模块(SIDE_MODULE)，这导致了符号类型定义的不一致。

正确的做法应该是：

1. 只在主模块中使用-sFETCH标志
2. 侧模块中不使用该标志

通过调整构建系统，确保-sFETCH标志仅应用于主模块，问题得到了解决。

技术背景

在WebAssembly的链接过程中，符号类型的严格一致性非常重要。当同一个符号在不同模块中被定义为不同类型（如DATA和FUNCTION）时，链接器无法确定应该采用哪种定义，因此会报错。

Emscripten的FETCH功能提供了一组用于网络请求的API，这些API需要在主模块中正确初始化。当这些符号同时在侧模块中被定义时，就可能出现类型不一致的情况。

最佳实践

对于类似的功能标志，开发者应当注意：

1. 功能标志通常应该只应用于主模块
2. 侧模块应该通过动态链接接口来使用这些功能
3. 在构建系统中明确区分主模块和侧模块的编译标志
4. 当遇到符号类型不匹配错误时，首先检查标志的应用范围

这个问题也提醒我们，在升级编译器工具链时，特别是LLVM这样的底层组件，可能会引入一些微妙的兼容性问题，需要开发者注意测试和验证。