<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.
