Emscripten: binaryen.js compilation issues with 1.37.23+

Created on 29 Dec 2017  路  29Comments  路  Source: emscripten-core/emscripten

It seems binaryen.js no longer compiles with 1.37.23 or newer (using emsdk's windows binaries).

Haven't tested 1.37.27 because there are no prebuilt binaries yet.

1.37.24, 1.37.25, 1.37.26

When --closure 1 is specified, compilation fails on invocation of closure compiler with exit code 1. Though -v doesn't provide more information, I assume that it happens for the same reason as below.

When --closure 1 is not specified, it compiles but loading binaryen.js errors with [TypeError: Cannot assign to read only property 'stack' of object 'Error: No such file or directory'] which originates somewhere around here. I've read somewhere that making the stack property writable: true where it's defined might solve this.

1.37.23 errors with Exception: closure compiler error: java.lang.UnsupportedClassVersionError: com/google/javascript/jscomp/CommandLineRunner : Unsupported major.minor version 52.0.

1.37.22 appears to be the last working version.

picture dcodeIO

Most helpful comment

Thanks - calling emsdk update should now update the manifest as well.

picture juj on 5 Feb 2018
👍2

All 29 comments

Haven't tested 1.37.27 because there are no prebuilt binaries yet.

So it seems the bot failed again. I think we need a new way to build them...

saschanaz picture saschanaz on 29 Dec 2017

Regarding 1.37.27, this is what emsdk tells me:

The following precompiled SDKs are available for download: (Run "./emsdk update" to pull in the latest list)
         sdk-nightly-1.37.9-2017_04_19_23_39-64bit
         sdk-nightly-1.37.9-2017_04_20_04_06-64bit
         sdk-1.30.0-64bit
         sdk-1.34.1-64bit
         sdk-1.35.0-64bit
         sdk-1.37.1-64bit
         sdk-1.37.25-64bit              INSTALLED
         sdk-1.37.26-64bit              INSTALLED
dcodeIO picture dcodeIO on 29 Dec 2017

Yeah, it seems the bot failed to generate new precompiled SDK. And AFAIK the compilation failure should be fixed on 1.37.27. (#5923)

saschanaz picture saschanaz on 29 Dec 2017

I think this might be a different problem, actually - if it's failing on closure, it's probably a new closure error from the new closure version. And we do test building binaryen.js on the bots now... but if Java isn't installed, closure is skipped.

But running this locally on binaryen master and emscripten incoming, I don't see a closure error. I do see a runtime error, which without closure looks like this:
TypeError: "stack" is read-only Stack: ensureErrnoError/<@a.js:1:201156 [email protected]:1:201064 [email protected]:1:201241 @a.js:1:230897 @a.js:1:52
That looks like a recent emscripten change to setting the stack in ensureErrnoError, I think by you @saschanaz ? Could explain why this fails on some machines but not others, as I think it was a workaround for some node.js version? A bigger question though might be why is binaryen.js using ErronoError or filesystem support at all, that seems wrong.

kripken picture kripken on 29 Dec 2017

Error happens on

FS.genericErrors[code].stack = "<generic error, no stack>"
kripken picture kripken on 29 Dec 2017

Ah yes, opened #5999.

saschanaz picture saschanaz on 29 Dec 2017

With 1.37.28 I'm seeing the following Closure Compiler error again:

  File "...\shared.py", line 2279, in closure_compiler
    raise Exception('closure compiler error: ' + process.stdout + ' (rc: %d)' % process.returncode)
Exception: closure compiler error: java.lang.UnsupportedClassVersionError: com/google/javascript/jscomp/CommandLineRunner : Unsupported major.minor version 52.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.access$100(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)
Exception in thread "main"  (rc: 1)
dcodeIO picture dcodeIO on 11 Jan 2018

Unsupported major.minor version 52.0

Does Closure Compiler now require Java 9? (52.0 is Java 8) Ah, this is because your Java version is lower than 52.0 (which means Java 8). That Java error message is unintuitive...

saschanaz picture saschanaz on 11 Jan 2018

Checking my emsdk directory, I see java/7.45_64bit there.

dcodeIO picture dcodeIO on 11 Jan 2018

Emscripten recentely updated Closure Compiler and the update version now requires Java 8. The updated emsdk (which you can get from https://github.com/juj/emsdk) provides Java 8.

saschanaz picture saschanaz on 11 Jan 2018

Thanks, replacing the JRE with a newer solves the issue as well.

dcodeIO picture dcodeIO on 11 Jan 2018
👍1

We probably should check Java version on sanity check to prevent this situation anyway...

saschanaz picture saschanaz on 11 Jan 2018

Just updated emsdk to master, still installs Java 7.45_64bit, edit but actually contains 1.8.0_77. Maybe my emsdk didn't notice because the directory name remained the same?

dcodeIO picture dcodeIO on 11 Jan 2018

That's strange, Java 8 is expected to be the default provided version now. Did you do emsdk install latest or something else?

saschanaz picture saschanaz on 11 Jan 2018

I always do

emsdk update
emsdk list
# pick the latest precompiled for windows
emsdk install sdk-1.37.28-64bit
emsdk activate sdk-1.37.28-64bit

Should I use latest?

dcodeIO picture dcodeIO on 11 Jan 2018

Heh, and suddenly it's 1.7.0_45-b18 again. Maybe 1.8.0_77 is my system Java or something.

dcodeIO picture dcodeIO on 11 Jan 2018

latest is just a shortcut which automatically picks sdk-1.37.28-64bit so there should be no differences. Hmm.

saschanaz picture saschanaz on 11 Jan 2018

What Node.js version do you get, BTW? It should be 8.9.1 instead of old 4.1.1.

saschanaz picture saschanaz on 11 Jan 2018

So it seems the bot failed again. I think we need a new way to build them...

This bug was resolved, and with emsdk update-tags, the 1.37.28 version should appear.

juj picture juj on 11 Jan 2018
👍1

Hi Guys I have also a problem with closure compiler :/

I would like to experiment with it after reading promising kripken's article:
https://hacks.mozilla.org/2018/01/shrinking-webassembly-and-javascript-code-sizes-in-emscripten/

So, I'm always updating EMSDK for windows via:

emsdk update
emsdk install latest

and after activation via:
emsdk activate latest --global

I've go this info:

MINGW_ROOT='w:/Emsdk/mingw/4.6.2_32bit'
LLVM_ROOT='w:/Emsdk/clang/e1.37.33_64bit'
EMSCRIPTEN_NATIVE_OPTIMIZER='w:/Emsdk/clang/e1.37.33_64bit/optimizer.exe'
BINARYEN_ROOT='w:/Emsdk/clang/e1.37.33_64bit/binaryen'
NODE_JS='w:/Emsdk/node/4.1.1_64bit/bin/node.exe'
PYTHON='w:/Emsdk/python/2.7.5.3_64bit/python.exe'
JAVA='w:/Emsdk/java/7.45_64bit/bin/java.exe'
EMSCRIPTEN_ROOT='w:/Emsdk/emscripten/1.37.33'
SPIDERMONKEY_ENGINE = ''
V8_ENGINE = ''
TEMP_DIR = 'c:/users/bartek/appdata/local/temp'
COMPILER_ENGINE = NODE_JS
JS_ENGINES = [NODE_JS]

Adding directories to PATH:
PATH += w:\Emsdk\clang\e1.37.33_64bit
PATH += w:\Emsdk\emscripten\1.37.33

Setting environment variables:
EMSDK = w:/Emsdk
EM_CONFIG = C:\Users\Bartek\.emscripten
BINARYEN_ROOT = w:\Emsdk\clang\e1.37.33_64bit\binaryen
EMSCRIPTEN = w:\Emsdk\emscripten\1.37.33

How can I update Java SDK to 8 and Node.JS to 8.9.1 version via EMSDK?

bsokol picture bsokol on 2 Feb 2018

Hmm, it sounds like some people are not getting the new Java update.. What happens if you run emsdk update-tags command explicitly instead of emsdk update? Does your emsdk_manifest.json file contain the following?

  {
    "version": "%precompiled_tag64%",
    "bitness": 64,
    "uses": ["clang-e%precompiled_tag64%-64bit", "node-8.9.1-64bit", "python-2.7.5.3-64bit", "java-8.152-64bit", "emscripten-%precompiled_tag64%"],
    "os": "win",
    "version_filter": [
      ["%precompiled_tag64%", ">", "1.37.22"]
    ]
  },
juj picture juj on 2 Feb 2018

Fwiw, this is my one at this point in time after update-tags/update. No signs of Java 8 or node 8 (I manually replaced them).

dcodeIO picture dcodeIO on 2 Feb 2018

Thanks @dcodeIO : with that file I think I now see what is going on. Working on deploying a fix..

juj picture juj on 2 Feb 2018

As a workaround you can try directly bootstrapping via git clone https://github.com/juj/emsdk.git

juj picture juj on 2 Feb 2018

It is my emsdk_manifest.json after emsdk update-tags :
https://pastebin.com/8RTy0REV

bsokol picture bsokol on 3 Feb 2018

Thanks - calling emsdk update should now update the manifest as well.

juj picture juj on 5 Feb 2018
👍2

Thanks! After normal update, install and activation I have already proper setup on windows! :)

Set the following tools as active:
   git-1.9.4
   mingw-7.1.0-64bit
   clang-e1.37.33-64bit
   node-8.9.1-64bit
   python-2.7.5.3-64bit
   java-8.152-64bit
   emscripten-1.37.33
bsokol picture bsokol on 5 Feb 2018

@juj Does the above mean this issue can be closed?

froydnj picture froydnj on 6 Feb 2018

Confirming that after emsdk update, emsdk install latest now installs the correct packages (node 8.9.1, java 8.152). Thanks!

dcodeIO picture dcodeIO on 6 Feb 2018
Was this page helpful?
0 / 5 - 0 ratings

Related issues

ShawZG picture ShawZG  路  4Comments
lokpoi888 picture lokpoi888  路  4Comments
jcfr picture jcfr  路  4Comments
kripken picture kripken  路  4Comments
yahsaves picture yahsaves  路  4Comments