Update to latest Emscripten

[StarGate01]

The current version of Emscripten used (2.0.12) works, but is quite old. An update would also maybe help with better WASI support (#7).

Currently, compilation and linking fails using versions 2.0.34 as well as 3.1.8 .

[tmm1]

I can poke at this. If you have the compilation/linker failures handy it would be useful to attach them here.

[tmm1]

I tried with 2.0.28 since I need emscripten-core/emscripten#14865

It fails as so:

...
#8 0.517 wasm-ld: warning: Linking two modules of different data layouts: 'lib/libgfortran.awrite.c.bc' is 'e-m:e-p:32:32-i64:64-f128:64-n32:64-S128-ni:1:10:20' whereas 'ld-temp.o' is 'e-m:e-p:32:32-i64:64-n32:64-S128'                                                              #8 0.517                                                                                                                                    
#8 0.522                                                                                                                                    #8 0.522 wasm-ld: warning: Linking two modules of different data layouts: 'lib/libgfortran.alist_read.c.bc' is 'e-m:e-p:32:32-i64:64-f128:64-n32:64-S128-ni:1:10:20' whereas 'ld-temp.o' is 'e-m:e-p:32:32-i64:64-n32:64-S128'                                                          
#8 0.522                                                                                                                                    
#8 0.526                                                                                                                                    
#8 0.526 wasm-ld: warning: Linking two modules of different data layouts: 'lib/libgfortran.atransfer.c.bc' is 'em:e-p:32:32-i64:64-f128:64-n32:64-S128-ni:1:10:20' whereas 'ld-temp.o' is 'e-m:e-p:32:32-i64:64-n32:64-S128'                                                           
#8 0.526                                                                                                                                    
#8 3.484 wasm-ld: /b/s/w/ir/cache/builder/emscripten-releases/llvm-project/llvm/lib/CodeGen/MachineFunction.cpp:203: void llvm::MachineFunction::init(): Assertion `Target.isCompatibleDataLayout(getDataLayout()) && "Can't create a MachineFunction using a Module with a " "Target-incompatible DataLayout attached\n"' failed.

[tmm1]

2.0.16: ok
2.0.18: ok
2.0.21: ok
2.0.22: ok
2.0.23: ok
2.0.25: ok
2.0.27: error
2.0.26: error

changelog https://github.com/emscripten-core/emscripten/blob/main/ChangeLog.md#2026---07262021
commit list emscripten-core/emscripten@2.0.25...2.0.26

[tmm1]

I'm not certain, but I think this may be related to a memory alignment change made for the emscripten build target in llvm:

llvm/llvm-project@d1a96e9
emscripten-core/emscripten#14634

there was another approach not involving llvm changes which was abandoned: emscripten-core/emscripten#14456

[StarGate01]

@tmm1 Thank you for testing! I can reproduce all the errors you are seeing. I suspect the LLVM toolchain was upgraded in Emscripten 2.0.27 in such a way that it became incompatible to llvm-3.3.

Unfortunately, the dragonegg GCC-to-LLVM compiler plugin used requires LLVM 3.3 specifically. I tried using forks that claim compatibility to higher GCC and/or LLVM versions, but these forks all had various bugs or shortcomings.

I thought about a few approaches to "upgrade" the bytecode generated by LLVM 3.3 to a more recent version that is understood by the toolchain included with the latest Emscripten. Rewriting the textual representation of the IR code proved to be complex, since the changes between versions don't neccessarily have a direct mapping between each other.

A different approach would be to disassemble the IR bytecode generated by LLVM 3.3 back into its textual representation, but using the most recent LLVM disassembler (llvm-dis) that still understands the 3.3 binary representation. Then, this more recent toolchain should be able to re-assemble the "upgraded" textual IR into IR bytecode, which could hopefully then be understood by the LLVM version used in the most recent Emscripten. The whole point of using the binary representation in the first place was because the Emscripten LLVM toolchain used to be able to parse it despite being much more recent - which was not possible when using the textual representation.

[tmm1]

Thanks. I did notice that emfc.sh rewrites the target datalayout line of the generated textual llvm output. Perhaps we just need to tweak that to match what newer llvm is doing with the rest of the objects being linked together?

Full-Stack-Fortran/f90wasm/scripts/emfc.sh

Lines 5 to 6 in bad7893

	sed -i 's/^\(target\sdatalayout\s*=\s*\).*$/\1"e-m:e-p:32:32-i64:64-n32:64-S128"/' "$OUT" && \
	sed -i 's/^\(target\striple\s*=\s*\).*$/\1"wasm32-unknown-emscripten"/' "$OUT" && \

These two sed lines result in the following changes to the gfortran output:

-target datalayout = "e-p:32:32:32-S128-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f16:16:16-f32:32:32-f64:32:64-f128:128:128-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32"
-target triple = "i386--linux-gnu"
+target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128"
+target triple = "wasm32-unknown-emscripten"

[tmm1]

Perhaps we just need to tweak that to match

Yep, I got it working. Will open PR shortly.

[tmm1]

2.0.28 now works too, which solves my original issue with exit code propagation.

I tried 2.0.34 but got this error:

#8 0.299 /app/emsdk/upstream/bin/clang: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory
#8 0.299 emcc: error: '/app/emsdk/upstream/bin/clang --version' failed (returned 127)

Will bisect again to see when that started.

[StarGate01]

Which data layout did you end up using?

I remember having issues with libpthread and libatomic in the past, these usually only concern multi-threaded systems. However, Emscripten requires an explicit configuration change to enable threading, see https://emscripten.org/docs/porting/pthreads.html .

Would be interesting to figure out which module requests linkage to libatomic - I don't think any of the libgfortran objects requires it, but I'd have to check.

[tmm1]

I added f128:64 and that seemed to be enough. (master...tmm1:update-emscripten)

2.0.31: ok
2.0.32: fails with libatomic reference

changelog https://github.com/emscripten-core/emscripten/blob/main/ChangeLog.md#2032---10192021
commit list emscripten-core/emscripten@2.0.31...2.0.32

--

I see, clang itself needs libatomic:

$ /app/emsdk/upstream/bin/clang --version
/app/emsdk/upstream/bin/clang: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

[StarGate01]

Adding libatomic1 to the packages installed via apt-get in the Dockerfile (tool stage) got rid of the error for me.

[tmm1]

Aha, I kept putting it in the wrong section. Confirmed working. Trying 2.0.34 next and will open a PR. Then we can try 3.x separately

[tmm1]

2.0.34 fails with another datalayout issue:

#7 0.518 wasm-ld: warning: Linking two modules of different data layouts: 'lib/libgfortran.a(size_from_kind.c.bc at 4308686)' is 'e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-f128:64-n32:64-S128-ni:1:10:20' whereas 'ld-temp.o' is 'e-m:e-p:32:32-i64:64-n32:64-f128:64-S128'

[tmm1]

2.0.33 also fails with that layout issue. I'll try adding p10:8:8-p20:8:8 into the mix.