Forwards/backwards compatibility between Emscripten versions?

[John Dallman]

<preface> I am not producing an application of any kind. I'm working on porting a large mathematical modelling library and its custom test harness to WebAssembly. This library is used in many different applications, some produced by my employers, and others produced by third-party ISVs who license it for their own applications. 

The library is commercial and closed source, with lots of confidential test data, so I have to test it myself and distribute it in binary form. This already happens on a range of x86- and ARM-based native code platforms. Producing the library in wasm form will allow some of the applications that use it to offer web versions.

Because the library's API is quite complex, and uses many C structs, I am not attempting to produce a JavaScript binding for it at first. The API design predates the existence of JavaScript and it was not designed for the limitations of the JavaScript to WebAssembly interface. Therefore, I am not attempting to produce a WebAssembly module. At least at first, it will be necessary to call the library from C/C++ code compiled to wasm. Since that's what the existing customers for the library are used to, it is acceptable to them. It's clear that the library will have to be callable from JavaScript to be more widely adopted in web applications. </preface>  

All this means that I need to provide the library to my customers as an archive library (aka static library) of .o files generated by Emscripten. On a conventional native code platform, I'd expect this to work OK. Provided all my customers were using a toolchain version the same as, or later than, the one I used to produce the archive library and the .o files within it, and there weren't incompatible compile options in use, this normally works. If I used a very old toolchain, I'd be at more risk of incompatibility, but I'm used to that. However, I've been learning from experience that Emscripten is fussier about some things than conventional native code compiling for C and C++. 

What compatibility should I expect between my archive libraries and customers using later versions of Emscripten? Getting all the customers to use the same version of Emscripten is obviously ideal, but very difficult to achieve in practice. 

Thanks in advance,

John

  

[Sam Clegg]

I'm afraid there is no simple answer here.

There are no official guarettes provided by emscripten about the compatibility of object files between emscripten versions.   However, in practice, this should almost always be fine. 

The core object file format, and the low level C / C++ ABI, have not changed since the LLVM backend first started writing object files (at least not that I can remember).   If it ever does change I'm sure that will come with some kind of linker error message when objects use different ABIs.

A more likely source of incompatibility would be in the low level C and emscripten headerss.   Imagine, for example that you have object files that use `embind.h` or the `EM_JS` / `EM_ASM` macros.  In theory we could change the definitions in our headers such that object files against older versions of the headers no longer work.   Another example would be if we decided, for some strange reason, to re-number the error codes in `errno.h`.    These kind of breakages are more likely the ABI / object format breakages but should still be very rare, and if you don't use the emscripten APIs/headers in your code then I would say they extremely unlikely.

In fact, I can't think of any specific case of this kind of breaking in recent years.

cheers,

sam

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqgkzT69osShSj%3DmSJZtXvw%3DncpqQO4prx2BcAdJSbuRQQg%40mail.gmail.com.