Actually, it looks like there are a few other targets that have the same issue already i386-apple-darwin and i386-pc-openbsd for example both exhibit the same problem. So I think fixing upstream is the way to go.
On Wed, Aug 8, 2018 at 3:11 PM Alon Zakai <[email protected]> wrote: > > 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. -- 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.
