emscripten-core / emscripten-core/emscripten
Incorrect library name passed to linker when linking with versioned dynamic libraries
- Dominant language
- C++
- Stars
- 27.6k
- Forks
- 3.6k
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 105
Description
After upgrading emscripten in nixpkgs, I found that `zlib` example is not building, failing at the step of seemingly building examples that have to be linked with just produced library.
Looking at the produced linker command, it appears that the library name passed to `wasm-ld` is incorrect.
This happened on emscripten 2.0.25 but the offending code appears to be unchanged between that and current main.
Here's the invoked command (with unrelated parts omitted for brevity):
```
/.../bin/emcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o examplesh example.o -L. libz.so.1.2.11
wasm-ld: error: unable to find library -lz.so.1.2
emcc: error: '/.../bin/wasm-ld -o examplesh.wasm example.o -L. -lz.so.1.2 [...]
```
Library file produced during compilation is called `libz.so.1.2.11` and is symlinked as
```
ln -s libz.so.1.2.11 libz.so
ln -s libz.so.1.2.11 libz.so.1
```
From these logs it's clear that `.11` part is getting chopped, as if it was an extension.
I went digging in `emcc.py` and found that [the call to `unsuffixed_basename`](https://github.com/emscripten-core/emscripten/blob/88fc9f0ea67aa7be76b2d482476ad3c08ab3cbb3/emcc.py#L1239) is likely to be incorrect, as it doesn't have the special logic for ignoring the library version extension part and acts as a normal `basename`.
After applying a local hack to do `libname = strip_prefix(arg[:arg.rfind(file_suffix)], 'lib')` instead (taking only the name part until the format suffix), the linking succeeded.
I'm not sure whether it should be passing version and what kind of a long-term solution would maintainers prefer so I refrained from opening a PR.
Contributor guide
Assessment
This issue has not been assessed yet.