This is a limitation of how we "fake" configure results. We invoke the native compiler but with our libraries and defines, so this can fail if types are different. The reason we do this is that configure can do anything natively - read/write to a file, open a process, etc., stuff we can't do in compiled JS.
There is an EMCONFIGURE_JS env var you can set, to force use of JS, which might help here. Perhaps we should default to EMCONFIGURE_JS, and force people to modify configure scripts the other way - but either way, there will be manual work. - Alon On Fri, Feb 6, 2015 at 3:23 PM, Boris Gjenero <[email protected]> wrote: > When running emconfigure ./configure, the detected data type sizes are > those of the host system. When configuring on a 64-bit system, long and > pointer sizes will be wrong: > checking size of unsigned long... 8 > checking size of int *... 8 > > Configure will succeed and the code will probably compile, but anything > depending on those sizes won't work properly. I know stdint.h or SDL types > can be used instead of those tests, but the fact remains that plenty of > software uses those Autoconf tests. If the data type sizes could be > detected properly this would be one less reason to add Emscripten-specific > stuff to Autoconf-related files. > > -- > 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.
