configure: error: compiler cannot create executables

[jplatte]

I've had trouble with this for quite some time but didn't yet have a closer look at the problem. When I change the configure.ac in my project and run "emmake make" in my emscripten build directory afterwards, the configure script is automatically regenerated and re-ran. For the re-running part, the flags passed on the last invocation are used again.

When searching for the root of this problem, I found the invocation of configure is inside the config.status script in the build directory. It can be manually triggered by calling the script with the --recheck option:

$ ./config.status --recheck

Then the configure script is executed:

running CONFIG_SHELL=/bin/sh /bin/sh ../configure CXX=/usr/lib/emscripten/em++ PKG_CONFIG_PATH= PKG_CONFIG_LIBDIR=/usr/lib/emscripten/system/local/lib/pkgconfig:/usr/lib/emscripten/system/lib/pkgconfig --no-create --no-recursion

which fails because

checking whether the C++ compiler works... no
configure: error: C++ compiler cannot create executables

Of course this doesn't happen when calling configure through emconfigure with the same arguments. Also, all of the command line arguments and environment variables are automatically set by emconfigure, they were not part of my emconfigure invocation.

The simplest solution I can think of is to use sed to manually change the functionality that invokes configure in config.status. It looks like this in my config.status file:

if $ac_cs_recheck; then
  set X /bin/sh '../configure'  'CXX=/usr/lib/emscripten/em++' 'PKG_CONFIG_PATH=' 'PKG_CONFIG_LIBDIR=/usr/lib/emscripten/system/local/lib/pkgconfig:/usr/lib/emscripten/system/lib/pkgconfig' $ac_configure_extra_args --no-create --no-recursion
  shift
  $as_echo "running CONFIG_SHELL=/bin/sh $*" >&6
  CONFIG_SHELL='/bin/sh'
  export CONFIG_SHELL
  exec "$@"
fi

[kripken]

It does seem like a good solution here is to modify the build system to not invoke configure "automatically" and unexpectedly.

[jplatte]

Why would this behaviour be unexpected? I find it quite practical that the configure script is automatically regenerated and re-ran when configure.ac changed like the object files and executables / libraries are recompiled (only) when the source files changed.

[kripken]

Well, I guess if you run configure through emconfigure in that case as well, it should all be fine.

[jplatte]

It would be. But config.status is a script automatically generated by configure (see Wikipedia). That's why I suggested just fixing it with sed in emconfigure, but I could imagine there is a better way of solving this.

[jplatte]

Today I stumbled upon the "compiler cannot create executables" error again. Only this time it was while using emconfigure (which means I can't build my emscripten project at all). Something seems to have seriously broken since somewhere between 1.34.6.75 and 1.34.6.123 (I'm sure it didn't work with the latter, and somewhat sure it did work with the former). I'm currently running 1.34.6.131 and experiencing this problem.

[kripken]

Can you bisect to a commit, or at least a range?

[jplatte]

Right. I'll see what I can do.

[jplatte]

Hmm, this has to be a problem introduced by autoconf, I can't find any release with which it works. I have autoconf 2.69.

EDIT: Its copyright says 2012. That can't be the problem...

[jplatte]

Okay, so I searched around a bit and found that emconfigure was supposed to set a different compiler (clang) during the configure stage and then go on with CC / CXX set to emcc / em++. I added CXX=clang++ to the configure invocation and then manually changed CXX in the generated Makefile, and this worked as far as the configure script is concerned. However, now I'm getting an error when linking, which I read any useful information in:

Traceback (most recent call last):
  File "/home/jonas/code/emscripten/emar", line 23, in <module>
    subprocess.call(newargs)
  File "/usr/lib/python2.7/subprocess.py", line 522, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1335, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

I really have no idea what's wrong, the only thing useful in there seems to be the last line that states that some file is missing...

EDIT: Hmmm, maybe I should have run emcc -v after one of the last updates. Sanity checks fail :S

[jplatte]

Well, in hindsight I should probably have created a new issue, but it doesn't seem like the original one will ever be fixed anyway... So, emconfigure does work when emscripten-fastcomp is available, although not the with the current version (or the current version just takes forever). I found 1.28.0 worked, so I'll see if I can find out the cause of this new behaviour where the check if the C++ compiler works doesn't fail, but takes very long, possibly not completing ever (I let it run for half a minute).

[jplatte]

So... The configure script fails when checking for the compiler version, as emcc --version runs the sanity checks and then returns non-0 when it finds a fastcomp version it doesn't expect. This makes bisecting pretty much impossible. I now managed to compile everything with my locally installed version of emscripten, 1.34.6. However, when creating the final .js file, I get a lot of warning: unresolved symbol:s about every symbol inside the two static libraries I link against. Why is everything broken since the last time I used Emscripten? ,_,

EDIT: Found the problem, had multiple Makefiles and didn't replace CXX in all of them.

[kripken]

It might be easier to bisect to revisions, which are tagged in the 3 repos (1.28.0, 1.28.1, etc.). Need to update all 3 repos together to each tag, and build fastcomp for each.

If that still doesn't work, then if you can make as small a standalone testcase as possible i can try to bisect.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past 2 years. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

[jplatte]

It's been years since I've last used emscripten, I don't know if this issue still exists and/or is relevant.