wasm-ld regression in 3.1.64: symbol type mismatch

[hoodmane]

In Emscripten 3.1.64, we start getting errors in building several libraries like follows:

wasm-ld: error: symbol type mismatch: crc32_z                                   
>>> defined as WASM_SYMBOL_TYPE_SECTION in                                      
/root/repo/packages/.libs/lib/libnetcdf.a(libdispatch_la-dcrc32.o)              
>>> defined as WASM_SYMBOL_TYPE_FUNCTION in                                     
/root/repo/packages/.libs/lib/libhdf5.so

Here's what wasm-ld outputs as the --repro:
a.tar.gz

wasm-ld @response.txt works fine with wasm-ld 3.1.63 but breaks on 3.1.64.

Version of emscripten/emsdk:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.64 (a1fe390)

[ryanking13]

I did some bisection, and this change looks related: llvm/llvm-project#75242 (cc: @sbc100)

It seems to add two new checks:

1. function signature mismatch check:

We (Pyodide) faced new signature mismatches in a few packages, and I think it is what the PR intended.

2. symbol type mismatch check:

This seems to be a secondary change in the PR, but it's the thing causing this issue.

Happens here: https://github.com/sbc100/llvm-project/blob/000519d1a3597cfb7e42b23a33f0989ad3ef1e4b/lld/wasm/SymbolTable.cpp#L370-L374

But I don't understand why it is misjudging a FUNCTION symbol as a SECTION.

[sbc100]

@ryanking13 are you also seeing mismatched between FUNCTION and SECTION symbols? I think llvm/llvm-project#75242 should only relate to shared libraries (which is it likely effects you), but this but looks like its not related to shared libraries, just simply object files.

[sbc100]

Sorry I misread the OP, this is indeed related to shared symbols.

[sbc100]

Fix in flight on the llvm side: llvm/llvm-project#124619

[ryanking13]

Thanks for the quick answer and fix!