Ok, can't quite build with incoming 64bit on Windows, I get this error
after linking:
em++ -s USE_SDL=2 -s TOTAL_MEMORY=268435456 -s DISABLE_EXCEPTION_CATCHING=1
-O2 -s ASSERTIONS=2 --preload-file
"D:/dev/monkey2/modules/mojo3d/tests/ducks.buildv1.1.09/emscripten_debug/assets/@/assets"
-s BINARYEN=1 -o
"D:/dev/monkey2/modules/mojo3d/tests/ducks.products/Emscripten/Ducks.js"
@tmp/lnkFiles1.txt
warning: unresolved symbol: glDrawBuffer
warning: unresolved symbol: glReadBuffer
Failed opening
'D:/dev/monkey2/modules/mojo3d/tests/ducks.products/Emscripten/Ducks.js.mem'
Traceback (most recent call last):
File "D:\devtools\emsdk-portable-64bit\emscripten\incoming\\em++", line
16, in <module>
emcc.run()
File "D:\devtools\emsdk-portable-64bit\emscripten\incoming\emcc.py", line
1876, in run
wasm_text_target, misc_temp_files, optimizer)
File "D:\devtools\emsdk-portable-64bit\emscripten\incoming\emcc.py", line
2348, in do_binaryen
subprocess.check_call(cmd)
File "D:\depot_tools\win_tools-2_7_6_bin\python\bin\lib\subprocess.py",
line 540, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['C:\\Users\\The
Razorback\\.emscripten_ports\\binaryen\\binaryen-version_40\\bin\\asm2wasm',
'D:/dev/monkey2/modules/mojo3d/tests/ducks.products/Emscripten/Ducks.temp.asm.js',
'--total-memory=268435456', '--trap-mode=allow', '-O2',
'--mem-init=D:/dev/monkey2/modules/mojo3d/tests/ducks.products/Emscripten/Ducks.js.mem',
'--mem-base=1024', '--wasm-only', '-o',
'D:/dev/monkey2/modules/mojo3d/tests/ducks.products/Emscripten/Ducks.wasm']'
returned non-zero exit status 1
Note: The glDrawBuffer and glReadBuffer warnings are kind of weird. These
are extensions in WebGL, and as far a I can work out, you just 'use them'
if they're in the GL_EXTENSIONS string without having to GetProcAddress
them or anything. No idea how this works, but it usually also works find in
wasm so I've just been ignoring these warnings.
I can build on macos and linux with incoming 64 bit fine though.
On Thu, Dec 28, 2017 at 10:15 PM, Mark Sibly <[email protected]> wrote:
> Yay, macos is finally going.
>
> I ended up having to install 'incoming', which meant a build from source
> which took a while but worked fine.
>
> As far as I can work out, all the precompiled sdks are borked due to the
> llvm-ar issue. I tried copying llvm-ar around between versions but gave up
> in the end.
>
> Incoming fixes the EXTRA_EXPORTED_RUNTIME_METHODS issue too, and of course
> has fixed TRAP_MODE and I assume lots else. Might be time to release a new
> precompiled SDK?
>
> On Thu, Dec 28, 2017 at 6:25 PM, Mark Sibly <[email protected]> wrote:
>
>> Is there perhaps another emsdk version with working llvm-ar?
>>
>>
>> On Thu, Dec 28, 2017 at 6:20 PM, Mark Sibly <[email protected]>
>> wrote:
>>
>>> Hi,
>>>
>>> Ok I can confirm macos doesn't like:
>>>
>>> EXTRA_EXPORTED_RUNTIME_METHODS="['Pointer_stringify']"
>>>
>>> is has to be:
>>>
>>> "EXTRA_EXPORTED_RUNTIME_METHODS=['Pointer_stringify']"
>>>
>>> Next problem is I seem to have hit this issue:
>>>
>>> https://github.com/kripken/emscripten/issues/5418
>>>
>>> The fix seems to be to use 'homebrew' llvm-ar instead.
>>>
>>> Any alternative to this?
>>>
>>>
>>> On Thu, Dec 28, 2017 at 5:25 PM, Mark Sibly <[email protected]>
>>> wrote:
>>>
>>>> Cool bananas.
>>>>
>>>> Am gonna have another go at installing emscripten on macos, have never
>>>> had much luck with that in the past...
>>>>
>>>>
>>>> On Thu, Dec 28, 2017 at 5:24 PM, Alon Zakai <[email protected]>
>>>> wrote:
>>>>
>>>>> I think that's a quoting issue, which
>>>>>
>>>>> https://github.com/kripken/emscripten/pull/5992
>>>>>
>>>>> gives a better error for, and adds documentation about. I merged that
>>>>> in now.
>>>>>
>>>>> On Wed, Dec 27, 2017 at 8:19 PM, Mark Sibly <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Well, this fixes it for me, but another user on mac is getting the
>>>>>> following error now when building:
>>>>>>
>>>>>> Traceback (most recent call last):
>>>>>> File “/Users/jesse/emsdk-portable/emscripten/1.37.27/em++”, line 16,
>>>>>> in <module>
>>>>>> emcc.run()
>>>>>> File “/Users/jesse/emsdk-portable/emscripten/1.37.27/emcc.py”, line
>>>>>> 912, in run
>>>>>> setattr(shared.Settings, key, eval(value))
>>>>>> File “<string>”, line 1, in <module>
>>>>>> NameError: name ‘Pointer_stringify’ is not defined
>>>>>>
>>>>>> On Thu, Dec 28, 2017 at 2:45 PM, Mark Sibly <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> > It adds a link to the FAQ at the top there, and the entry it links
>>>>>>> to is more detailed. How does it look now?
>>>>>>>
>>>>>>> Much better!
>>>>>>>
>>>>>>> Will add -O3 for link too, thanks.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Dec 28, 2017 at 1:57 PM, Alon Zakai <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Yeah, that's the right fix - sorry about this, we've made changes
>>>>>>>> there recently, and the docs should be better. I opened
>>>>>>>>
>>>>>>>> https://github.com/kripken/emscripten/pull/5994
>>>>>>>>
>>>>>>>> now with some improvements, and pushed it live at
>>>>>>>>
>>>>>>>> http://kripken.github.io/emscripten-site/docs/api_reference/
>>>>>>>> module.html
>>>>>>>>
>>>>>>>> It adds a link to the FAQ at the top there, and the entry it links
>>>>>>>> to is more detailed. How does it look now?
>>>>>>>>
>>>>>>>> About your flags, they look mostly good, but make sure you have -O3
>>>>>>>> for link as well as compiling object files.
>>>>>>>>
>>>>>>>> Btw, another option you might want to try is
>>>>>>>> BINARYEN_IGNORE_IMPLICIT_TRAPS, which can help a little with
>>>>>>>> size/speed, but like TRAP_MODE it may not work on all code (so it's
>>>>>>>> off by
>>>>>>>> default).
>>>>>>>>
>>>>>>>> On Wed, Dec 27, 2017 at 4:43 PM, Mark Sibly <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Yay, sort of fixed it, ended up adding this to my 'linker' options
>>>>>>>>> (where linker=ec++):
>>>>>>>>>
>>>>>>>>> -s EXTRA_EXPORTED_RUNTIME_METHODS=['Pointer_stringify']
>>>>>>>>>
>>>>>>>>> Is this the 'right' fix?
>>>>>>>>>
>>>>>>>>> Actually, I have a bunch of build/link switches now that I'm not
>>>>>>>>> really sure about. For compiling source code I use:
>>>>>>>>>
>>>>>>>>> -std=c++11 -O3 -DNDEBUG -s USE_SDL=2 -s TOTAL_MEMORY=268435456 -s
>>>>>>>>> DISABLE_EXCEPTION_CATCHING=1
>>>>>>>>>
>>>>>>>>> Are all these necessary or are some only needed for linking? For
>>>>>>>>> linking I use:
>>>>>>>>>
>>>>>>>>> -s USE_SDL=2 -s TOTAL_MEMORY=268435456 -s
>>>>>>>>> DISABLE_EXCEPTION_CATCHING=1 -s BINARYEN=1 -s
>>>>>>>>> BINARYEN_TRAP_MODE='allow' -s EXTRA_EXPORTED_RUNTIME_METHODS
>>>>>>>>> =['Pointer_stringify']
>>>>>>>>>
>>>>>>>>> Ditto, are these all necessary?
>>>>>>>>>
>>>>>>>>> The goal here is to create the *fastest* code!
>>>>>>>>>
>>>>>>>>> On Thursday, December 28, 2017 at 1:32:43 PM UTC+13, Mark Sibly
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> My wasm apps have started producing the following error with a
>>>>>>>>>> fresh install of emsdk 'latest' on Windows 10:
>>>>>>>>>>
>>>>>>>>>> > 'Pointer_stringify' was not exported. add it to
>>>>>>>>>> EXTRA_EXPORTED_RUNTIME_METHODS (see the FAQ)
>>>>>>>>>>
>>>>>>>>>> This error didn't used to happen before on a different install -
>>>>>>>>>> sorry but I can't remember the version.
>>>>>>>>>>
>>>>>>>>>> em++ -v gives me:
>>>>>>>>>>
>>>>>>>>>> emcc (Emscripten gcc/clang-like replacement + linker emulating
>>>>>>>>>> GNU ld) 1.37.26
>>>>>>>>>> clang version 4.0.0 (emscripten 1.37.26 : 1.37.26)
>>>>>>>>>> Target: x86_64-pc-windows-msvc
>>>>>>>>>> Thread model: posix
>>>>>>>>>> InstalledDir: D:\devtools\emsdk-portable-64b
>>>>>>>>>> it\clang\e1.37.26_64bit
>>>>>>>>>> INFO:root:(Emscripten: Running sanity checks)
>>>>>>>>>>
>>>>>>>>>> I did find this page:
>>>>>>>>>>
>>>>>>>>>> http://kripken.github.io/emscripten-site/docs/api_reference/
>>>>>>>>>> module.html?highlight=extra_exported_runtime_methods#overrid
>>>>>>>>>> ing-execution-environment
>>>>>>>>>>
>>>>>>>>>> Which mentions exporting functions using
>>>>>>>>>> EXTRA_EXPORTED_RUNTIME_METHODS but I have no idea what that means.
>>>>>>>>>>
>>>>>>>>>> I would greatly appreciate any help here.
>>>>>>>>>>
>>>>>>>>>> Bye,
>>>>>>>>>> Mark
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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 a topic in
>>>>>>>> the Google Groups "emscripten-discuss" group.
>>>>>>>> To unsubscribe from this topic, visit
>>>>>>>> https://groups.google.com/d/topic/emscripten-discuss/m-GobZu
>>>>>>>> 3Tm0/unsubscribe.
>>>>>>>> To unsubscribe from this group and all its topics, 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 a topic in the
>>>>> Google Groups "emscripten-discuss" group.
>>>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>>>> pic/emscripten-discuss/m-GobZu3Tm0/unsubscribe.
>>>>> To unsubscribe from this group and all its topics, 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.
