The missing uglify-js comment is a bug on the Nightly uploader part, I'm
working on that one.

(Marked down https://github.com/juj/emslave/issues/1 and at a larger scale,
https://github.com/kripken/emscripten/issues/4836)

2016-12-12 19:53 GMT+02:00 'Derek Schuff' via emscripten-discuss <
[email protected]>:

> I think the reason that both types of binaries (those built with gcc4 and
> gcc5) work with the newer libstdc++ is that it has both older and newer
> versions of the relevant symbols. For example:
>
> $ readelf -s ~/Downloads/libstdc++.so.6.0.21
> ... <symbol dump>
> 84: 00000000000c6ee0    50 FUNC    WEAK   DEFAULT   12
> _ZNSt15basic_stringbufIwS@@GLIBCXX_3.4
> ...
> 265: 00000000000c6c20   380 FUNC    WEAK   DEFAULT   12
> _ZNSt15basic_stringbufIwS@@GLIBCXX_3.4.21
>
> This is done exactly so that software complied against older libstdc++
> will still work. So newer libstdc++ should work for you. However if you
> build things on a newer system and try to run them on an older system,
> you'll need to also watch out for possible similar versioning issues from
> any other shared libs that the binaries depend on; most notably libc. One
> possible way to work around this for libstdc++ is that gcc has a flag
> -static-libstdc++ that causes libstdc++ to be linked statically rather than
> dynamically, so there will be no runtime dependence on libstdc++ in the
> resulting binary. So for the SDK prebuilts we could build our tools with
> that flag to hopefully avoid this problem. In the PNaCl toolchain we build
> the toolchain on a quite-old version of Ubuntu (this avoids libc and other
> issues) but this means that we have to build and bundle our own copy of
> libc++ because the version of libstdc++ on that system isn't new enough to
> build LLVM.
>
> On Fri, Dec 9, 2016 at 12:48 PM <[email protected]> wrote:
>
>> Hi,
>>
>> I've now done a fresh checkout of emsdk and followed the instructions you
>> posted in https://github.com/kripken/emscripten/issues/4682#
>> issuecomment-260159020 .  Unfortunately I still experienced some issues
>> with the prebuilt Clang and Emscripten distributions. This was on a 64bit
>> Ubuntu 14.04 box. Fortunately I did manage to work around these issue.
>> Details below:
>>
>> The binary toolchain downloaded fine, and the SDK activated fine.
>> Unfortunately emcc would not run:
>>
>> ljw@ljw-desktop:~/src/emsdk$ ./emsdk activate --embedded
>> sdk-nightly-latest-64bit
>> Writing .emscripten configuration file to Emscripten SDK directory
>> /home/ljw/src/emsdk
>> The Emscripten configuration file /home/ljw/src/emsdk/.emscripten has
>> been rewritten with the following contents:
>>
>> import os
>> emsdk_path=os.path.dirname(os.environ.get('EM_CONFIG')).replace('\\',
>> '/')
>> LLVM_ROOT='' + emsdk_path + '/clang/nightly-e1.36.14-2016_12_08_07_01'
>> NODE_JS='' + emsdk_path + '/node/4.1.1_64bit/bin/node'
>> EMSCRIPTEN_ROOT='' + emsdk_path + '/emscripten/nightly-1.36.14-
>> 2016_12_08_07_01'
>> SPIDERMONKEY_ENGINE = ''
>> V8_ENGINE = ''
>> TEMP_DIR = '' + emsdk_path + '/tmp'
>> COMPILER_ENGINE = NODE_JS
>> JS_ENGINES = [NODE_JS]
>>
>> To conveniently access the selected set of tools from the command line,
>> consider adding the following directories to PATH, or call 'source
>> ./emsdk_env.sh' to do this for you.
>>
>>    /home/ljw/src/emsdk:/home/ljw/src/emsdk/clang/nightly-
>> e1.36.14-2016_12_08_07_01:/home/ljw/src/emsdk/node/4.1.1_
>> 64bit/bin:/home/ljw/src/emsdk/emscripten/nightly-1.36.14-2016_12_08_07_01
>> ljw@ljw-desktop:~/src/emsdk$ source ./emsdk_env.sh
>> Adding directories to PATH:
>> PATH += /home/ljw/src/emsdk
>> PATH += /home/ljw/src/emsdk/clang/nightly-e1.36.14-2016_12_08_07_01
>> PATH += /home/ljw/src/emsdk/node/4.1.1_64bit/bin
>> PATH += /home/ljw/src/emsdk/emscripten/nightly-1.36.14-2016_12_08_07_01
>>
>> Setting environment variables:
>> EMSDK = /home/ljw/src/emsdk
>> EM_CONFIG = /home/ljw/src/emsdk/.emscripten
>> EM_CACHE = /home/ljw/src/emsdk/.emscripten_cache
>> EMSCRIPTEN = /home/ljw/src/emsdk/emscripten/nightly-1.36.14-
>> 2016_12_08_07_01
>>
>> I then ran emcc and got the following error:
>>
>> ljw@ljw-desktop:~/src/emsdk$ emcc
>> CRITICAL:root:Could not verify LLVM version: argument of type 'NoneType'
>> is not iterable
>> /home/ljw/src/emsdk/clang/nightly-e1.36.14-2016_12_08_07_01/llc:
>> /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not
>> found (required by /home/ljw/src/emsdk/clang/nightly-e1.36.14-2016_12_08_
>> 07_01/llc)
>> /home/ljw/src/emsdk/clang/nightly-e1.36.14-2016_12_08_07_01/llc:
>> /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not
>> found (required by /home/ljw/src/emsdk/clang/nightly-e1.36.14-2016_12_08_
>> 07_01/llc)
>> CRITICAL:root:fastcomp in use, but LLVM has not been built with the
>> JavaScript backend as a target, llc reports:
>> ============================================================
>> ===============
>> (no targets could be identified: need more than 1 value to unpack)
>> ============================================================
>> ===============
>> CRITICAL:root:you can fall back to the older (pre-fastcomp) compiler
>> core, although that is not recommended, see http://kripken.github.io/
>> emscripten-site/docs/building_from_source/LLVM-Backend.html
>> INFO:root:(Emscripten: Running sanity checks)
>> CRITICAL:root:failing sanity checks due to previous fastcomp failure
>>
>> As I mentioned in my previous message, the "'GLIBCXX_*' not found" errors
>> above are due to emscripten-fastcomp being built with GCC 5.X. In order to
>> run these programs I needed a copy of libstdc++.so from GCC5. Building GCC5
>> would be time consuming, so I instead obtained an appropriate libstdc++.so
>> binary from the ubuntu-toolchain-r PPA. I didn't want to modify my host
>> system so I downloaded the deb, verified and extracted it, and then put the
>> libstdc++.so in my path:
>>
>> wget http://ppa.launchpad.net/ubuntu-toolchain-r/test/
>> ubuntu/pool/main/g/gcc-5/libstdc++6_5.1.0-0ubuntu11~10.04.2_amd64.deb
>> wget http://ppa.launchpad.net/ubuntu-toolchain-r/test/
>> ubuntu/dists/lucid/Release
>> wget http://ppa.launchpad.net/ubuntu-toolchain-r/test/
>> ubuntu/dists/lucid/Release.gpg
>> wget http://ppa.launchpad.net/ubuntu-toolchain-r/test/
>> ubuntu/dists/lucid/main/binary-amd64/Packages
>>
>> Note that I've downloaded the Lucid version (Ubuntu 10.04). I just did
>> this so I could use the same binary on both Ubuntu 12.04 and 14.04 (though
>> I've not tested 12.04 yet).
>>
>> mv Release.gpg Release.asc
>>
>> Then verified:
>>
>> ljw@ljw-desktop:~/src/emsdk/my_deb$ gpg --verify Release.asc
>> gpg: Signature made Sun 26 Apr 2015 05:11:17 BST using RSA key ID BA9EF27F
>> gpg: Good signature from "Launchpad Toolchain builds"
>> gpg: WARNING: This key is not certified with a trusted signature!
>> gpg:          There is no indication that the signature belongs to the
>> owner.
>> Primary key fingerprint: 60C3 1780 3A41 BA51 845E  371A 1E93 77A2 BA9E
>> F27F
>>
>> ljw@ljw-desktop:~/src/emsdk/my_deb$ sha256sum Packages
>> fed61ce85f21b5a5e9c5d9e6c76ad3f5b24a775750fff61c5b224e2c8357f606
>>  Packages
>> ljw@ljw-desktop:~/src/emsdk/my_deb$ grep fed61ce85f21b5a5e9c5d9e6c76ad3
>> f5b24a775750fff61c5b224e2c8357f606 Release
>>  fed61ce85f21b5a5e9c5d9e6c76ad3f5b24a775750fff61c5b224e2c8357f606
>>     328682 main/binary-amd64/Packages
>> ljw@ljw-desktop:~/src/emsdk/my_deb$ sha256sum
>> libstdc++6_5.1.0-0ubuntu11~10.04.2_amd64.deb
>> 3742f82b49b214f03c3531dd63be860ee63409788497f1b368cd465cabb5ec1c
>>  libstdc++6_5.1.0-0ubuntu11~10.04.2_amd64.deb
>> ljw@ljw-desktop:~/src/emsdk/my_deb$ grep 3742f82b49b214f03c3531dd63be86
>> 0ee63409788497f1b368cd465cabb5ec1c -A 9 -B 15 Packages
>> Package: libstdc++6
>> Source: gcc-5
>> Priority: important
>> Section: libs
>> Installed-Size: 2040
>> Maintainer: Ubuntu Core developers <[email protected]
>> >
>> Architecture: amd64
>> Version: 5.1.0-0ubuntu11~10.04.2
>> Replaces: libstdc++6-5-dbg (<< 4.9.0-3)
>> Depends: gcc-5-base (= 5.1.0-0ubuntu11~10.04.2), libc6 (>= 2.11), libgcc1
>> (>= 1:4.1.1)
>> Conflicts: scim (<< 1.4.2-1)
>> Filename: pool/main/g/gcc-5/libstdc++6_5.1.0-0ubuntu11~10.04.2_amd64.deb
>> Size: 525688
>> MD5sum: 91e20fab6550dbe12ba4287a2cabc737
>> SHA1: 4f79929ae9f17ab7ca95fbd9b9629c1ec8c66421
>> SHA256: 3742f82b49b214f03c3531dd63be860ee63409788497f1b368cd465cabb5ec1c
>> Description: GNU Standard C++ Library v3
>>  This package contains an additional runtime library for C++ programs
>>  built with the GNU compiler.
>>  .
>>  libstdc++-v3 is a complete rewrite from the previous libstdc++-v2, which
>>  was included up to g++-2.95. The first version of libstdc++-v3 appeared
>>  in g++-3.0.
>> Original-Maintainer: Debian GCC Maintainers <[email protected]>
>>
>> I then extracted the deb and put the libstdc++.so in my LD_LIBRARY_PATH:
>>
>> ljw@ljw-desktop:~/src/emsdk/my_deb$ ar xv libstdc++6_5.1.0-0ubuntu11~10.
>> 04.2_amd64.deb
>> x - debian-binary
>> x - control.tar.gz
>> x - data.tar.gz
>> ljw@ljw-desktop:~/src/emsdk/my_deb$ tar xvf data.tar.gz
>> ./
>> ./usr/
>> ./usr/lib/
>> ./usr/lib/libstdc++.so.6.0.21
>> ...
>> ./usr/lib/libstdc++.so.6
>> ./usr/share/doc/libstdc++6
>> ljw@ljw-desktop:~/src/emsdk/my_deb$ cd usr/lib/
>> ljw@ljw-desktop:~/src/emsdk/my_deb/usr/lib$ ls
>> libstdc++.so.6  libstdc++.so.6.0.21
>> ljw@ljw-desktop:~/src/emsdk/my_deb/usr/lib$ export
>> LD_LIBRARY_PATH=${PWD}:$LD_LIBRARY_PATH
>>
>> I was then able to run emcc:
>>
>> ljw@ljw-desktop:~$ emcc
>> INFO:root:(Emscripten: Running sanity checks)
>> WARNING:root:no input files
>>
>> I then attempted to run:
>>
>> python $EMSCRIPTEN/embuilder.py build ALL
>>
>> This was mostly successful, but it errored out building the
>> native_optimizer:
>>
>> INFO:root:building and verifying native_optimizer
>> module.js:338
>>     throw err;
>>     ^
>>
>> Error: Cannot find module '../tools/eliminator/node_modules/uglify-js'
>>     at Function.Module._resolveFilename (module.js:336:15)
>>     at Function.Module._load (module.js:286:25)
>>     at Module.require (module.js:365:17)
>>     at require (module.js:384:17)
>>     at Object.<anonymous> (/home/ljw/src/emsdk/
>> emscripten/nightly-1.36.14-2016_12_08_07_01/tools/js-optimizer.js:132:14)
>>     at Module._compile (module.js:434:26)
>>     at Object.Module._extensions..js (module.js:452:10)
>>     at Module.load (module.js:355:32)
>>     at Function.Module._load (module.js:310:12)
>>     at Function.Module.runMain (module.js:475:10)
>> Traceback (most recent call last):
>>   File 
>> "/home/ljw/src/emsdk/emscripten/nightly-1.36.14-2016_12_08_07_01/emcc",
>> line 13, in <module>
>>     emcc.run()
>>   File 
>> "/home/ljw/src/emsdk/emscripten/nightly-1.36.14-2016_12_08_07_01/emcc.py",
>> line 1877, in run
>>     JSOptimizer.flush()
>>   File 
>> "/home/ljw/src/emsdk/emscripten/nightly-1.36.14-2016_12_08_07_01/emcc.py",
>> line 1773, in flush
>>     run_passes(chunks[0], title, just_split=False, just_concat=False)
>>   File 
>> "/home/ljw/src/emsdk/emscripten/nightly-1.36.14-2016_12_08_07_01/emcc.py",
>> line 1746, in run_passes
>>     final = shared.Building.js_optimizer(final, passes, debug_level >=
>> 4, JSOptimizer.extra_info, just_split=just_split, just_concat=just_concat)
>>   File "/home/ljw/src/emsdk/emscripten/nightly-1.36.14-
>> 2016_12_08_07_01/tools/shared.py", line 1829, in js_optimizer
>>     ret = js_optimizer.run(filename, passes, NODE_JS, debug, extra_info,
>> just_split, just_concat)
>>   File "/home/ljw/src/emsdk/emscripten/nightly-1.36.14-
>> 2016_12_08_07_01/tools/js_optimizer.py", line 559, in run
>>     return temp_files.run_and_clean(lambda: run_on_js(filename, passes,
>> js_engine, source_map, extra_info, just_split, just_concat))
>>   File "/home/ljw/src/emsdk/emscripten/nightly-1.36.14-
>> 2016_12_08_07_01/tools/tempfiles.py", line 78, in run_and_clean
>>     return func()
>>   File "/home/ljw/src/emsdk/emscripten/nightly-1.36.14-
>> 2016_12_08_07_01/tools/js_optimizer.py", line 559, in <lambda>
>>     return temp_files.run_and_clean(lambda: run_on_js(filename, passes,
>> js_engine, source_map, extra_info, just_split, just_concat))
>>   File "/home/ljw/src/emsdk/emscripten/nightly-1.36.14-
>> 2016_12_08_07_01/tools/js_optimizer.py", line 378, in run_on_js
>>     asm_shell_pre, asm_shell_post = minifier.minify_shell(asm_shell,
>> 'minifyWhitespace' in passes, source_map).split('EMSCRIPTEN_FUNCS();');
>>   File "/home/ljw/src/emsdk/emscripten/nightly-1.36.14-
>> 2016_12_08_07_01/tools/js_optimizer.py", line 247, in minify_shell
>>     assert len(output) > 0 and not output.startswith('Assertion failed'),
>> 'Error in js optimizer: ' + output
>> AssertionError: Error in js optimizer:
>> Traceback (most recent call last):
>>   File "/home/ljw/src/emsdk/emscripten/nightly-1.36.14-
>> 2016_12_08_07_01/embuilder.py", line 147, in <module>
>>     ''', ['optimizer.2.exe'], ['-O2'])
>>   File "/home/ljw/src/emsdk/emscripten/nightly-1.36.14-
>> 2016_12_08_07_01/embuilder.py", line 69, in build
>>     shared.Building.emcc(temp, args, output_filename=temp_js)
>>   File "/home/ljw/src/emsdk/emscripten/nightly-1.36.14-
>> 2016_12_08_07_01/tools/shared.py", line 1722, in emcc
>>     assert os.path.exists(output_filename), 'emcc could not create
>> output file: ' + output_filename
>> AssertionError: emcc could not create output file:
>> /home/ljw/src/emsdk/tmp/tmpMioyG3.js
>>
>> For some reason uglify-js does not seem to be distributed with the
>> Emscripten tarball downloaded by emsdk. Is this intended? I was able to
>> resolve this issue by copying across tools/eliminator/node_modules from a
>> git checkout of Emscripten.
>>
>> I'm also slightly dubious about my approach of using libstdc++.so from
>> GCC5. This makes emscripten-fastcomp binaries work, but I expected it to
>> fail when I attempted to run the native optimizer. The native optimizer
>> will be built using the system copy of GCC 4.8. This will link against
>> libstdc++ from GCC 4.8, but at runtime (due to the LD_LIBRARY_PATH) it will
>> run against the libstdc++ from GCC5. In theory these two versions of
>> libstdc++ are ABI incompatible for C++11 code. I ran python tests/runner.py
>> random100 and got no unexpected failures (other than SIMD/pthread stuff).
>> Maybe we got lucky and the native optimizer just doesn't happen to hit any
>> of the incompatible ABI paths. I suppose that if it did become a problem I
>> could just reset the LD_LIBRARY_PATH whenever executing the native
>> optimizer.
>>
>> Thanks
>> Liam Wilson
>>
>>
>> On Thursday, 8 December 2016 08:19:14 UTC, jj wrote:
>>
>> Oh, the command is actually "emsdk update-tags" and not "emsdk update
>> -tags".
>>
>> When you are using emsdk via git, "emsdk update" should not be used.
>> (marked down a note to improve emsdk to detect when it's being used via git
>> to make this obvious)
>>
>> The "emsdk update-tags" feature is a new one, which is not yet present in
>> the latest bundled version, which is why it got confused here.
>>
>> Try following the command line presented at https://github.com/kripken/
>> emscripten/issues/4682#issuecomment-260159020 to the letter. Verified
>> this to work locally, the run should look like this:
>>
>> C:\code\emsdk>emsdk update-tags
>> Fetching all tags from Emscripten Github repository...
>> Done. 86 tagged releases available, latest is 1.36.14.
>> Fetching all precompiled Nightly versions..
>> Downloading: C:/code/emsdk/llvm-nightlies-32bit.txt from
>> https://s3.amazonaws.com/mozilla-games/emscripten/
>> packages/llvm/nightly/win_32bit/index.txt
>> Downloading: C:/code/emsdk/llvm-nightlies-64bit.txt from
>> https://s3.amazonaws.com/mozilla-games/emscripten/
>> packages/llvm/nightly/win_64bit/index.txt
>> Downloading: C:/code/emsdk/emscripten-nightlies.txt from
>> https://s3.amazonaws.com/mozilla-games/emscripten/
>> packages/emscripten/nightly/win/index.txt
>>
>> C:\code\emsdk>emsdk install sdk-nightly-latest-64bit
>> Installing SDK 'sdk-nightly-1.36.14-2016_11_11_00_55-64bit'..
>> Installing tool 'clang-nightly-e1.36.14-2016_11_11_00_55-64bit'..
>> Downloading: C:/code/emsdk/zips/emscripten-llvm-e1.36.14-2016_11_11_00_55.zip
>> from https://s3.amazonaws.com/mozilla-games/emscripten/
>> packages/llvm/nightly/win_64bit/emscripten-llvm-e1.36.
>> 14-2016_11_11_00_55.zip
>> ...
>>
>> Try doing a fresh git clone to undo the changes that "emsdk update" did
>> on the git repository.
>>
>>
>> 2016-12-06 2:32 GMT+02:00 <[email protected]>:
>>
>> I'm having a bit of trouble downloading the precompiled binaries using
>> the instructions from https://github.com/kripken/emscripten/issues/4682#
>> issuecomment-260159020
>>
>> (precise)ljw@localhost:~/src/emsdk$ ./emsdk update -tags
>> Downloading: /home/ljw/src/emsdk/zips/emsdk_unix_update.tar.gz from
>> https://s3.amazonaws.com/mozilla-games/emscripten/
>> packages/emsdk_unix_update.tar.gz
>> Unpacking '/home/ljw/src/emsdk/zips/emsdk_unix_update.tar.gz' to
>> '/home/ljw/src/emsdk'
>> emsdk_portable/emscripten-tags.txt
>> emsdk_portable/emsdk
>> emsdk_portable/emsdk_env.sh
>> emsdk_portable/emsdk_manifest.json
>> emsdk_portable/README.md
>> Fetching all tags from Emscripten Github repository...
>> Done. 86 tagged releases available, latest is 1.36.14.
>> Fetching all precompiled Nightly versions..
>> Downloading: /home/ljw/src/emsdk/llvm-nightlies-32bit.txt from
>> https://s3.amazonaws.com/mozilla-games/emscripten/
>> packages/llvm/nightly/linux_32bit/index.txt
>> Downloading: /home/ljw/src/emsdk/llvm-nightlies-64bit.txt from
>> https://s3.amazonaws.com/mozilla-games/emscripten/
>> packages/llvm/nightly/linux_64bit/index.txt
>> Downloading: /home/ljw/src/emsdk/emscripten-nightlies.txt from
>> https://s3.amazonaws.com/mozilla-games/emscripten/
>> packages/emscripten/nightly/linux/index.txt
>> (precise)ljw@localhost:~/src/emsdk$ ./emsdk install
>> sdk-nightly-latest-64bit
>> Error: No tool or SDK found by name 'sdk-nightly-latest-64bit'.
>>
>> I did manage to download a fastcomp binary directly from
>> https://s3.amazonaws.com/mozilla-games/emscripten/
>> packages/llvm/nightly/linux_64bit/emscripten-llvm-latest.tar.gz .
>> Unfortunately the downloaded binary will not run on Ubuntu 12.04 or 14.04.
>> I see the following error:
>>
>> (precise)ljw@localhost:~/Downloads/fastcomp/emscripten-
>> llvm-e1.36.14-2016_12_04_02_39$ ./clang
>> ./clang: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version
>> `GLIBCXX_3.4.18' not found (required by ./clang)
>> ./clang: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version
>> `GLIBCXX_3.4.20' not found (required by ./clang)
>> ./clang: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version
>> `GLIBCXX_3.4.21' not found (required by ./clang)
>>
>> This suggests clang was built with some GCC 5.X (based on the symbol
>> versioning doc: https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
>> "GCC 5.1.0: GLIBCXX_3.4.21, CXXABI_1.3.9"). I assume it was built with GCC
>> 5.3 on Ubuntu 16.04?
>>
>> I came up with the following solution. I built emscripten-fastcomp under
>> Centos 6. This involved building GCC 4.8.5 and Cmake 3.5.2 under Centos 6.
>> I then used my freshly built GCC and CMake to build emscripten-fastcomp.
>> This gave me a fastcomp binary that only depends on glibc 2.12 and the
>> version of libstdc++ that ships with GCC 4.8.5. I also set up Emscripten
>> under Centos 6 and ran a chunk of the test suite. This involves building
>> Python 2.7 from source and installing prebuilt binaries of node.js,
>> Spidermonkey, and the JRE. With a bit of fiddling around I was able to put
>> together a Emscripten 1.36.14 binary distribution that worked on Centos 6,
>> Ubuntu 12.04 and Ubuntu 14.04 (and in theory a wide range of other 64bit
>> Linux distribution).
>>
>> Very rough instructions to this approach here: https://gist.github.com/
>> cosinusoidally/16ad712d2659dbf4f65a1d823ae35fbd
>>
>> Thanks
>> Liam Wilson
>>
>>
>> On Sunday, 4 December 2016 01:40:20 UTC, jj wrote:
>>
>> The Emscripten build bots do precompiled Nightly builds and upload them
>> to S3. https://github.com/kripken/emscripten/issues/4682#
>> issuecomment-260159020 has the command line steps to bootstrap to the
>> latest Nightlies.
>>
>> 2016-11-27 16:18 GMT+02:00 Juha Järvi <[email protected]>:
>>
>> To get Emscripten working quickly with Travis tests
>> <https://github.com/charto/nbind/blob/master/bin/ci-trigger> in nbind
>> <https://github.com/charto/nbind#readme> I copied the strategy used in
>> Urho3D <https://urho3d.github.io/> (see the html5 build) and removed the
>> Ruby dependency. Basically I set up a new nearly empty Github repo
>> <https://github.com/charto/nbind-ci-emscripten>, wrote the script in the
>> first link in this post and forked Urho3D's precompiled Emscripten repo
>> <https://github.com/urho3d/emscripten-sdk>. It doesn't get updated all
>> the time, but often enough for me.
>>
>>
>> tiistai 8. marraskuuta 2016 19.06.14 UTC+2 Shlomi Fish kirjoitti:
>>
>> Hi all!
>>
>> I'm using Emscripten to convert Freecell Solver's source code
>> ( http://fc-solve.shlomifish.org/ ) for use in the online site. I'd like
>> to add
>> the site's build+tests process to fc-solve's Travis-CI continuous
>> integration
>> process and Emscripten is part of its "make stage". Travis-CI gives me an
>> Ubuntu LTS x86-64 VM and allows setting up PPAs or fetching binaries, but
>> building Emscripten completely from source will be too time consuming and
>> prohibitive.
>>
>> Can anyone refer me to a PPA or precompiled binaries suitable for
>> installing and running on Ubuntu x86-64 for Emscripten? I'll be grateful
>> for
>> any insights.
>>
>> Regards,
>>
>>         Shlomi Fish
>>
>> --
>> -----------------------------------------------------------------
>> Shlomi Fish       http://www.shlomifish.org/
>> https://youtu.be/GoEn1YfYTBM - Tiffany Alvord - “Fall Together”
>>
>> It does not mean what I think it means, but it means what *you* think it
>> means.
>>
>> Please reply to list if it's a mailing list post - http://shlom.in/reply
>> .
>>
>> --
>> 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.
>>
>>
>> --
>> 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.
>

-- 
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.

Reply via email to