There is a second case, a (non-open source) game middleware library, where we saw this too. Same issue, with size_t being implicitly assumed to be one of the int*_t types (so the templates there end up matching nothing).
On Wed, Aug 8, 2018 at 3:02 PM Dan Gohman <[email protected]> wrote: > One of the main benefits of making size_t be unsigned long is that it > eliminates some C++ name mangling differences between wasm32 and wasm64. If > we change either int32_t or int64_t, it would introduce new name mangling > differences. > > If we find more issues, we should reevaluate the options, but so far we > only know of one case, and it's already fixed upstream, and there's a > workaround posted in this thread as well. > > Dan > > On Wed, Aug 8, 2018, 10:58 AM 'Sam Clegg' via emscripten-discuss < > [email protected]> wrote: > >> I'm running into this same issue internally too. >> >> Its seems kind of unfortunate that `intptr_t*` is neither compatible >> with `int64_t*` nor `int32_t*`. The code in question (which has thus >> far been fairly portable) seems to make this assumption. Could/Should >> we change `int32_t*` so that it also `long` and therefore >> interchangeable with `size_t`? >> On Fri, Jul 27, 2018 at 11:53 AM Dan Gohman <[email protected]> wrote: >> > >> > Hello, >> > >> > The change you described to ProtobufOnceType here seems like it should >> work. Going forward, this code in newer versions of protobuf has changed >> and looks like it should avoid this problem. This patch: >> > >> > >> https://github.com/google/protobuf/commit/0400cca3236de1ca303af38bf81eab332d042b7c#diff-c1a3f69dda9164a2db00255845f17a34R97 >> > >> > changed the type of ProtobufOnceType. >> > >> > Dan >> > >> > >> > On Fri, Jul 27, 2018 at 2:30 AM, Александр Гурьянов < >> [email protected]> wrote: >> >> >> >> I believe that protobuf have this defenition of types (for 32bit >> build): >> >> >> >> typedef int32 Atomic32; >> >> typedef int64 Atomic64; >> >> >> >> typedef intptr_t AtomicWord; >> >> typedef internal::AtomicWord ProtobufOnceType; >> >> >> >> AtomicWord should be same as Atomic32, so if you say that intptr_t >> still >> >> remains 32bit integer then easiest fix will be: >> >> >> >> Change in atomicops.h defenition of AtomicWord to: >> >> >> >> #ifdef EMSCRIPTEN >> >> typedef Atomic32 AtomicWord; >> >> #else >> >> typedef intptr_t AtomicWord; >> >> #endif >> >> >> >> This will not be safe if "things" are changed. If I force protobuf to >> 64bit, >> >> error still there because Atomic64 will be long long, but intptr_t >> >> long. Probably it's >> >> better to compile with -DGOOGLE_PROTOBUF_NO_THREAD_SAFETY, but I never >> >> have success >> >> to building it with that flag. >> >> >> >> Anyway now it works. >> >> пт, 27 июл. 2018 г. в 10:58, Александр Гурьянов <[email protected]>: >> >> > >> >> > I think because with this change now I can't compile protobuf >> library, >> >> > with this error: >> >> > >> >> > protobuf-3.0.2/src/google/protobuf/stubs/once.h:135:30: error: cannot >> >> > initialize a parameter of type 'const volatile >> >> > google::protobuf::internal::Atomic32 *' (aka 'const volatile int *') >> >> > with an lvalue of type 'google::protobuf::ProtobufOnceType *' (aka >> >> > 'long *') >> >> > if (internal::Acquire_Load(once) != ONCE_STATE_DONE) { >> >> > >> >> > I just found this error, I will keep your updated if I can solve it. >> >> > >> >> > вт, 24 июл. 2018 г. в 19:33, Alon Zakai <[email protected]>: >> >> > > >> >> > > On incoming and 1.38.10 we landed >> >> > > >> >> > > https://github.com/kripken/emscripten/pull/5916 >> >> > > >> >> > > which changes the type of size_t etc. from int to long. This helps >> synchronize the asm.js and wasm ABIs, and will be convenient for future >> versions of wasm (wasm64). >> >> > > >> >> > > This should not be noticeable in most cases, as it remains a >> 32-bit integer. However, if you depend on the name mangling of a C++ >> function that uses `size_t` (like in `EXPORTED_FUNCTIONS`), then the name >> might change slightly ('m' replaces 'j' for size_t). You also need to >> rebuild source files to bitcode so your bitcode is in sync with the system >> libraries after they are rebuilt with this change (rebuilding for any new >> version is recommended anyhow - we rebuild system libraries at that time). >> Finally, printf of a size_t using %u etc. may now show a warning (but is >> harmless), which you can avoid with adding a z, %zu etc. >> >> > > >> >> > > - Alon >> >> > > >> >> > > -- >> >> > > 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]. >> >> > > For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> >> 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]. >> >> For more options, visit https://groups.google.com/d/optout. >> > >> > >> > -- >> > 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]. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> 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]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > 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]. > For more options, visit https://groups.google.com/d/optout. > -- 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]. For more options, visit https://groups.google.com/d/optout.
