Can't configure erlang/otp, size of short/int/long/... == 0

[ivan]

When running under emconfigure, configuring otp fails with:

checking size of short... 0
checking size of int... 0
checking size of long... 0
checking size of long long... 0
checking size of __int128_t... 0
configure: error: No 32-bit type found

The checks in the top-level configure script work and output:

checking size of short... 2
checking size of int... 4
checking size of long... 8
checking size of void *... 8
checking size of long long... 8

while the errors come from erts/configure script that configure calls. I've tried running erts/configure by itself with emconfigure as well, but I see the same configure errors.

Repro steps are:

# wget https://s3.amazonaws.com/mozilla-games/emscripten/releases/emsdk-portable.tar.gz
# tar -xf emsdk-portable.tar.gz
# cd emsdk_portable
# ./emsdk install sdk-incoming-64bit
# . ./emsdk_env.sh 
Adding directories to PATH:
PATH += /home/build-otp/emsdk_portable
PATH += /home/build-otp/emsdk_portable/clang/fastcomp/build_incoming_64/bin
PATH += /home/build-otp/emsdk_portable/node/4.1.1_64bit/bin
PATH += /home/build-otp/emsdk_portable/emscripten/incoming

Setting environment variables:
EM_CONFIG = /home/build-otp/.emscripten
EMSCRIPTEN = /home/build-otp/emsdk_portable/emscripten/incoming

# emsdk activate sdk-incoming-64bit

# cd ~/
# git clone -b master --depth=100 https://github.com/erlang/otp
# cd otp
# ./otp_build autoconf
# emconfigure ./configure --without-termcap --without-javac --without-ssl --disable-threads --disable-smp-support --disable-kernel-poll --disable-sctp --disable-hipe

This might be the same issue as #264, but I haven't found a workaround. I see the same results when running emconfigure with EMCONFIGURE_JS=1, and there is no -O20 (or similar) in the configure scripts.

I also see the same with emscripten sdk-master-64bit and with the maint branch of otp.

Any suggestions would be appreciated, because I don't know my way around autoconf and configure.

[ivan]

Possibly caused by a linker failure; I'll go investigate:

configure:9842: checking size of long
configure:9847: /home/build-otp/emsdk_portable/emscripten/incoming/emcc -o conftest  -I/home/build-otp/otp/erts/x86_64-unknown-linux-gnu    -D_GNU_SOURCE  -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -D_POSIX_THREAD_SAFE_FUNCTI
ONS -D_GNU_SOURCE   conftest.c -lutil -linet -lm   -lpthread  -lrt >&5
/usr/bin/ld: cannot find -linet
clang-3.9: error: linker command failed with exit code 1 (use -v to see invocation)
configure:9847: $? = 1
configure: program exited with status 1
configure: failed program was:
[...]
configure:9861: result: 0

[ivan]

I made erts/configure pass these checks by deleting two instances of -linet.

In any case, this seems like a really odd failure mode. I think the configure script might be running the binary for the previous test, even when linking fails for the binary for the current test. It should error out earlier. But I'm not sure if emscripten has anything to do with it.

[juj]

In general configure scripts need to be developed to be aware that they are cross-compiling with Emscripten. Very often this kind of work is in the emulation land, we have a collection of hacks with emconfigure to try to make it mimic a native linux-like environment, but that is always not enough. If the project has a CMake build script, that might work better, since CMake has a strong concept of cross-compilation that Emscripten supports (there's a cross-compiler tool definition system for CMake).

To fake some configure scripts to succeed, we can run configure scripts against native gcc/ld, and use the results of that to feed to emcc. There was an env. var to control when that machinery is active, but don't remember what it was off the top of my head. Try checking the emconfigure file it that might have more info.

[ivan]

Thanks! I think you're referring to EMCONFIGURE_JS? In this case, setting to to 2 (always use) results in... blank output for the sizes of all the types.

Anyway, I ended up removing all the instances of AC_CHECK_SIZEOF and replacing them with a block of

ac_cv_sizeof_char=1
ac_cv_sizeof_double=8
ac_cv_sizeof_float=4
ac_cv_sizeof_int=4
ac_cv_sizeof_long=4
ac_cv_sizeof_long_double=12
ac_cv_sizeof_long_long=8
ac_cv_sizeof_short=2
ac_cv_sizeof_signed_char=1
ac_cv_sizeof_unsigned_int=4
ac_cv_sizeof_unsigned_long=4
ac_cv_sizeof_unsigned_long_long=8
ac_cv_sizeof_unsigned_short=2
ac_cv_sizeof_unsigned_short=2
ac_cv_sizeof_void_p=4
ac_cv_sizeof_off_t=4

and now I'm dealing with much more interesting compilation failures.

[ivan]

Or perhaps CONFIGURE_CC?