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



On Sun, Feb 15, 2026 at 7:58 AM John Dallman <[email protected]> wrote:

> <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
>
>
> --
> 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 [email protected].
> To view this discussion visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqgkzT69osShSj%3DmSJZtXvw%3DncpqQO4prx2BcAdJSbuRQQg%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqgkzT69osShSj%3DmSJZtXvw%3DncpqQO4prx2BcAdJSbuRQQg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAL_va29yN%2BTDeg-BznAQ%3DcWbyrToURCtQiZQDHfOFQQUco2LRw%40mail.gmail.com.

Reply via email to