bug: Emscripten doesn't generate PIC libc

[hoodmane]

Tested

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.9-git (7e4a0ae4bdd99abbbf299c025aa2ce7b339c8521)
clang version 15.0.0 (https://github.com/llvm/llvm-project b2a7f1c3904ede781565c6ed772f155167aa8325)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /home/hood/Documents/programming/emsdk/upstream/bin

Example:
test.c:

int f(x){
	return x+4;
}

emcc -c test.c -o test.o -fPIC
emcc test.o -o test.so -sSIDE_MODULE=1 -lc

fails with:

wasm-ld: error: unable to find library -lc
emcc: error: '/src/emsdk/emsdk/upstream/bin/wasm-ld -o tst.so --whole-archive tst.o -lc -L/src/emsdk/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/pic --no-whole-archive -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --import-undefined --import-memory --strip-debug --export-all --no-gc-sections --experimental-pic -shared' failed (returned 1)

[hoodmane]

Or probably it makes no sense to link -lc against a side module and we should be filtering out?

[kripken]

Does replacing -fPIC with -sMAIN_MODULE fix this perhaps? (we don't have full dynamic linking support, just the limited model of main and side modules)

[hoodmane]

Well what works for me is just filtering out -lc. I'm building a Rust package (the Python cryptography package) and cargo generates a linker invocation with -lc. Everything works fine if I just drop -lc in my linker wrapper before handing the invocation to emcc.

[hoodmane]

So perhaps I should close this as resolved?

[kripken]

Oh, ignore my comment on main module, I misread those commands...

I'm not sure where we landed on automatically ignoring redundant link libraries like -lc. @sbc100 ?

[sbc100]

When building a side module we don't add -lc automatically like we do normally. However, if you explicitly ask for it we don't ignore it.

I think its probably bug that we don't auto-build wasm32-emscripten/pic/libc.a here.

[sbc100]

On the other hand you almost certainly don't want to be including libc in your side module... I'm not sure if its best to just ignore it or to give a warning in this case?

[hoodmane]

Yeah we are filtering it out. Maybe dropping it and printing a warning would be best?

[kleisauke]

I think PR #19405 might be an alternative solution for this.

[kleisauke]

Or, if possible(?), perhaps we could avoid that rust passes -lc to the linker.

$ rustc --target=wasm32-unknown-emscripten --crate-type staticlib --print native-static-libs - < /dev/null
note: Link against the following native artifacts when linking against this static library. The order and any duplication can be significant on some platforms.

note: native-static-libs: -lc

[hoodmane]

Well the rust people rejected my suggestions to adjust rust since in their opinion passing -shared -lc is totally reasonable. I think it is reasonable:

gcc -shared -lc side.c -o side.so

works fine and same with clang. So Emscripten is really doing the wrong thing here by failing. We currently pass -Z link-native-libraries=no but this requires using nightly rust.

I also don't think #19405 is the right solution for this particular problem because we don't really want or need to actually link anything extra into the .so file. The native compilers produce exactly the same output whether -lc is passed or not and Emscripten should too IMO.

[hoodmane]

@katietz ran into this problem today trying to build libpng.so. It comes up in other contexts too, not just when building rust.

[hoodmane]

But #19405 does look independently helpful. I guess we should check if the #19405 solution has the same code size in the output as this solution. If they are the same code size, then that solution is indeed strictly better.

[sbc100]

I think #19405 probably won't fix your issue, since you really don't want to link libc.a into both your main module and your side module. That could lead to all kind of problems I think.