Bug#775147: emscripten: does not work at all with optimization enabled

Sun Jan 11 23:15:33 UTC 2015

Package: emscripten
Version: 1.22.1-1
Severity: grave
Justification: renders package almost completely unusable

I cannot seem to get emscripten to compile anything with -O1 or -O2 or
-O3 (specifying -O0 or no -O option appears to work for simple examples,
but possibly not for more complex code, see below). I hope I am not
doing something completely wrong, since this is my first time using
emscripten...

For example, even the simplest code I could think of fails:

$ echo 'int main() { return 0; }' >foo.c
$ rm -r ~/.emscripten* /tmp/emscripten_temp* ; emcc ; EMCC_DEBUG=1 emcc -O2 -o foo.html foo.c
[... lots of output snipped, full output in attached output-1.txt.gz ...]
INFO     root: =======================================
INFO     root: bootstrapping relooper...
INFO     root:   bootstrap phase 1
WARNING  root: LLVM version appears incorrect (seeing "3.5.0-9", expected "3.4")
INFO     root: (Emscripten: Running sanity checks)
clang: warning: argument unused during compilation: '-nostdinc++'
Exception in thread Thread-3:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 763, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 380, in _handle_result
s                                                                              
    task = get()
TypeError: ('__init__() takes at least 3 arguments (1 given)', <class 'subproces
s.CalledProcessError'>, ())                                                    

... and then it hangs waiting for something until I abort it with
Ctrl-C. After that, amid a few Python stack traces, it outputs:

ERROR    root: bootstrapping relooper failed. You may need to manually create re
looper.js by compiling it, see src/relooper/emscripten                         

Because of the LLVM version warning above, I also installed the
packages clang-3.4 and llvm-3.4 and tried to use those versions by
setting LLVM_ROOT like this:

$ rm -r ~/.emscripten* /tmp/emscripten_temp* ; emcc ; sed -i "s,^LLVM_ROOT =.*,LLVM_ROOT = '/usr/lib/llvm-3.4/bin'," ~/.emscripten ; EMCC_DEBUG=1 emcc -O2 -o foo.html foo.c

but it hanged in the same way (full output in attached output-2.txt.gz).
(I couldn't just remove llvm-3.5 and clang-3.5 entirely, since the
emscripten package depends on clang which currently depends on
clang-3.5. If the version really matters in some cases, perhaps
emscripten should depend on a specific LLVM version and use it by
default?)

Without optimizations, the compilation works:

$ rm -r ~/.emscripten* /tmp/emscripten_temp* ; emcc ; EMCC_DEBUG=1 emcc -o foo.html foo.c
[... full output in attached output-3.txt.gz ...]
DEBUG    root: generating HTML
DEBUG    root: emcc step "final emitting" took 0.18 seconds
DEBUG    root: total time: 17.98 seconds

The options -O1 and -O3 do not work either, but -O0 works. Compiling
some other small tests from /usr/share/emscripten/tests (e.g.
files.cpp) fails in the same way.

Using separate compilation (emcc -O2 -c foo.c ; emcc -O2 -o foo.html
foo.o) also fails in the same way. However, specifying -O0 to the link
command (emcc -O2 -c foo.c ; emcc -O0 -o foo.html foo.o) seems to work
at least for this simple example.

Even without optimizations, I am not sure if emscripten works for more
complex code: I originally ran into this bug trying to compile SDL 2
(upstream Mercurial version, commenting out a few lines because Debian's
emscripten is too old for some functions that it uses) and an SDL-using
application. I then tried inserting CFLAGS=-O0 for the configure script
of SDL and the Makefile of my application, but ran into the same bug
anyway. However, I guess it's possible that one file somewhere got
compiled with optimizations, since the build process is quite complex.
The command that failed (the very last link command, the only one with
-o something.html) did have -O0, and it still failed.

In any case, this bug does appear to make real-world use of Debian's
current emscripten package at least very difficult if not impossible -
thus the release-critical bug severity. (Feel free to downgrade if you
disagree, of course.)

At some point in my testing (unfortunately I couldn't find out how to
reproduce it) I got an LLVM error message relating to the weak_alias
directive on the last line of
/usr/share/emscripten/system/lib/libc/musl/src/stdio/vfscanf.c.
Inspired by upstream emscripten commit
d1fc0b645060c32681d9a1bec169c39a9f3e2a5c, I tried commenting the line
out, but the compilation did not seem to work any better (however, I
did get somewhat different error messages after that, so perhaps it is
somehow related?). I also tried the current emscripten upstream version
of vfscanf.c, without success.

Besides this 2-core laptop, I also tried compiling using a 1-core
virtual machine. Otherwise it was the same, but I did not need to press
Ctrl-C to abort emscripten, and the Python error messages / stack traces
were different (perhaps the thread pool system mentioned in the errors
is not used with only 1 core).

I would appreciate it if someone who reads this would try to reproduce
the problem, e.g., with the two first commands at the start of this bug
report. (Just to confirm that the problem is universal and not something
specific to my Debian installations.)

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages emscripten depends on:
ii  clang                     1:3.5-25
ii  libclosure-compiler-java  20130227+dfsg1-8
ii  llvm                      1:3.5-25
ii  node-uglify               2.4.15-1
ii  nodejs                    0.10.29~dfsg-1.1
pn  python:any                <none>

[I also have openjdk-7-jdk and openjdk-7-jre version 7u71-2.5.3-2
installed - the emscripten package does not depend on a Java runtime
even though it depends on a Java library, but I will file a separate bug
about that.]

emscripten recommends no packages.

emscripten suggests no packages.

-- no debconf information

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output-1.txt.gz
Type: application/octet-stream
Size: 6765 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-llvm-team/attachments/20150112/3cb033a9/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output-2.txt.gz
Type: application/octet-stream
Size: 7112 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-llvm-team/attachments/20150112/3cb033a9/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output-3.txt.gz
Type: application/octet-stream
Size: 6383 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-llvm-team/attachments/20150112/3cb033a9/attachment-0005.obj>