emsdk "latest" now uses the new build infrastructure

Alon Zakai

unread,

May 29, 2019, 1:45:45 PM5/29/19

to emscripte...@googlegroups.com

If you get emsdk master, and do

emsdk install latest

emsdk activate latest

then it will install 1.38.33 (or later, if there is one by the time you read this) from the new emscripten-releases build infrastructure. We've done some early testing recently as mentioned here:

https://groups.google.com/d/msg/emscripten-discuss/WhDtqVyW_Ak/8DfDnfk0BgAJ

After fixing some issues, there seem to be no showstoppers, so this is us moving to the next stage in the transition from the old builders to the new ones. (If all goes well then the stage after this will be to remove those old builders.)

Please report any issues you see!

Known issue: "no version information" warning on some linux machines, https://github.com/emscripten-core/emscripten/issues/8697, that we need to figure out.

- Alon

Floh

unread,

May 30, 2019, 7:37:39 AM5/30/19

to emscripten-discuss

It's "mostly" working fine here (tested with "latest"):

- Linux and OSX work out of the box (maybe because I have "accidentally" Java installed.

- on Windows running the Closure pass fails because of missing Java

Will Java be provided by emsdk or do I need to care of that myself?

And some "nice-to-have" feedback:

- Is it already time to write tickets for the latest-releases-upstream version? Compilation with my code appears to work, but I'm getting runtime errors for EM_JS functions:

failed to asynchronously prepare wasm: LinkError: WebAssembly.instantiate(): Import #61 module="env" function="_sapp_js_create_textfield" error: function import requires a callable

clear-sapp.html:39 LinkError: WebAssembly.instantiate(): Import #61 module="env" function="_sapp_js_create_textfield" error: function import requires a callable

- The very first emcc invocation after another SDK version is installed/activated (in my case during the cmake compiler detection) takes *very* long on Windows, something like 5..10 minutes, and without feedback, so it appears like the build process hangs. Under the hood there's some compilation happening (maybe binaryen?). The time this takes is so "uncomfortably long" that I would consider it a bug. May be in the future it would make sense to also provide precompiled artifacts for those hidden compilations for the "prebuilt" SDK versions?

Cheers,

-Floh.

Alon Zakai

unread,

May 30, 2019, 9:53:14 AM5/30/19

to emscripte...@googlegroups.com

On Thu, May 30, 2019 at 4:37 AM Floh <flo...@gmail.com> wrote:

It's "mostly" working fine here (tested with "latest"):

- Linux and OSX work out of the box (maybe because I have "accidentally" Java installed.
- on Windows running the Closure pass fails because of missing Java

Will Java be provided by emsdk or do I need to care of that myself?

Thanks, it looks like we used to bundle java on windows, but nowhere else. I opened

https://github.com/emscripten-core/emsdk/pull/253

to match that behavior on the new builds.

And some "nice-to-have" feedback:

- Is it already time to write tickets for the latest-releases-upstream version? Compilation with my code appears to work, but I'm getting runtime errors for EM_JS functions:

failed to asynchronously prepare wasm: LinkError: WebAssembly.instantiate(): Import #61 module="env" function="_sapp_js_create_textfield" error: function import requires a callable
clear-sapp.html:39 LinkError: WebAssembly.instantiate(): Import #61 module="env" function="_sapp_js_create_textfield" error: function import requires a callable

Definitely file bugs on upstream if you find any! Yes, please file this one with a testcase, it doesn't look like a known issue.

- The very first emcc invocation after another SDK version is installed/activated (in my case during the cmake compiler detection) takes *very* long on Windows, something like 5..10 minutes, and without feedback, so it appears like the build process hangs. Under the hood there's some compilation happening (maybe binaryen?). The time this takes is so "uncomfortably long" that I would consider it a bug. May be in the future it would make sense to also provide precompiled artifacts for those hidden compilations for the "prebuilt" SDK versions?

Did it not say what it was doing during that pause? Like it should say if it was building binaryen, or system libraries, etc. It should print that even without EMCC_DEBUG=1 in the env, but that may provide even more info.

We do provide binaryen pre-built, but not system libraries (but we plan to). If it's building binaryen from source, thats a bug. (I don't think we even download the binaryen sources, though.)

5-10 minutes sounds extremely long for either binaryen or system libraries, though. Was that on a slow machine? If not, then that sounds bad. Perhaps python doesn't detect how many cores there are and the builds are single-core, or maybe somehow our build of LLVM is debug and not release, or something like that?

- Alon

Cheers,
-Floh.

On Wednesday, 29 May 2019 19:45:45 UTC+2, Alon Zakai wrote:
If you get emsdk master, and do

emsdk install latest
emsdk activate latest

then it will install 1.38.33 (or later, if there is one by the time you read this) from the new emscripten-releases build infrastructure. We've done some early testing recently as mentioned here:

https://groups.google.com/d/msg/emscripten-discuss/WhDtqVyW_Ak/8DfDnfk0BgAJ

After fixing some issues, there seem to be no showstoppers, so this is us moving to the next stage in the transition from the old builders to the new ones. (If all goes well then the stage after this will be to remove those old builders.)

Please report any issues you see!

Known issue: "no version information" warning on some linux machines, https://github.com/emscripten-core/emscripten/issues/8697, that we need to figure out.

- Alon

--
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 emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/3ee49945-abce-4a0e-8814-69e38a1f1d49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Floh

unread,

May 30, 2019, 10:16:42 AM5/30/19

to emscripten-discuss

Did it not say what it was doing during that pause? Like it should say if it was building binaryen, or system libraries, etc. It should print that even without EMCC_DEBUG=1 in the env, but that may provide even more info.

No output, it happens during cmake's compiler / compile feature detection. Maybe cmake is supressing console output on purpose there to not spam the console with errors that might be expected during the detection.

5-10 minutes sounds extremely long for either binaryen or system libraries, though. Was that on a slow machine? If not, then that sounds bad. Perhaps python doesn't detect how many cores there are and the builds are single-core, or maybe somehow our build of LLVM is debug and not release, or something like that?

It's not a particularly slow laptop, I have set it up for Win10 / Ubuntu dual boot, and the same process on Linux is about the same as on my Mac laptop (which is acceptable). I think it's a Windows issue, IME clang on Windows is a lot slower than on OSX or Linux for some reason.

Maybe the Windows build is accidentally using a debug build of LLVM, I didn't pay attention to this, and it was downloading a prebuilt package, so that would be hard to notice anyway.

Cheers,

-Floh.

Alon Zakai

unread,

May 30, 2019, 10:26:52 AM5/30/19

to emscripte...@googlegroups.com

On Thu, May 30, 2019 at 7:16 AM Floh <flo...@gmail.com> wrote:

Did it not say what it was doing during that pause? Like it should say if it was building binaryen, or system libraries, etc. It should print that even without EMCC_DEBUG=1 in the env, but that may provide even more info.

No output, it happens during cmake's compiler / compile feature detection. Maybe cmake is supressing console output on purpose there to not spam the console with errors that might be expected during the detection.

Ah, this was when you ran cmake on your project? Yeah, it might hide the output.

Would be interesting to see in a fresh install what happens when building a hello world on windows, where the output isn't hidden.

5-10 minutes sounds extremely long for either binaryen or system libraries, though. Was that on a slow machine? If not, then that sounds bad. Perhaps python doesn't detect how many cores there are and the builds are single-core, or maybe somehow our build of LLVM is debug and not release, or something like that?

It's not a particularly slow laptop, I have set it up for Win10 / Ubuntu dual boot, and the same process on Linux is about the same as on my Mac laptop (which is acceptable). I think it's a Windows issue, IME clang on Windows is a lot slower than on OSX or Linux for some reason.

Maybe the Windows build is accidentally using a debug build of LLVM, I didn't pay attention to this, and it was downloading a prebuilt package, so that would be hard to notice anyway.

Cheers,
-Floh.

--

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 emscripten-disc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/56218175-49c2-4199-a291-39296350452a%40googlegroups.com.

Floh

unread,

May 30, 2019, 1:54:06 PM5/30/19

to emscripten-discuss

Would be interesting to see in a fresh install what happens when building a hello world on windows, where the output isn't hidden.

It's libc which takes so long:

cache:INFO: generating system library: libc.bc... (this will be cached in...

Floh

unread,

May 30, 2019, 3:33:19 PM5/30/19

to emscripten-discuss

Definitely file bugs on upstream if you find any! Yes, please file this one with a testcase, it doesn't look like a known issue.

Here's the link to the ticket:

https://github.com/emscripten-core/emscripten/issues/8712

It's really trivial to reproduce here, and the problem disappears when switching to 'latest'.

Cheers,

-Floh.

Alon Zakai

unread,

May 30, 2019, 10:35:01 PM5/30/19

to emscripte...@googlegroups.com

About compiling libc which takes so long - is compiling your own code slower as well?

--

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 emscripten-disc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/c678df7b-5330-4170-8e65-11c35a1d96b2%40googlegroups.com.

Floh

unread,

May 31, 2019, 3:39:42 AM5/31/19

to emscripten-discuss

> About compiling libc which takes so long - is compiling your own code slower as well?

Yes, compiling my own code is also slower, but I've seen this since forever for the same stuff compiled via clang on OSX/Linux vs Windows. I just started to accept it as some weird clang oddity ;)

I haven't installed / activated emscripten SDKs so often in the past on Windows though, so I didn't notice this as much as now.

On Friday, 31 May 2019 04:35:01 UTC+2, Alon Zakai wrote:

About compiling libc which takes so long - is compiling your own code slower as well?

On Thu, May 30, 2019 at 10:54 AM Floh <flo...@gmail.com> wrote:

Would be interesting to see in a fresh install what happens when building a hello world on windows, where the output isn't hidden.

It's libc which takes so long:

cache:INFO: generating system library: libc.bc... (this will be cached in...

--
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 emscripten-discuss+unsub...@googlegroups.com.

Alon Zakai

unread,

May 31, 2019, 1:24:51 PM5/31/19

to emscripte...@googlegroups.com

Thanks for the info, interesting.

I doublechecked and we do build LLVM in release mode, on Windows and elsewhere. We do build with assertions on all platforms, which is something we can perhaps remove for speed, but it is useful.

Another possible issue is that we use Python multiprocess code to compile libraries (so we use all cores), and I've heard it's slower on windows for various reasons. Perhaps there is something faster? I opened https://github.com/emscripten-core/emscripten/issues/8719

- Alon

On Fri, May 31, 2019 at 12:39 AM Floh <flo...@gmail.com> wrote:

> About compiling libc which takes so long - is compiling your own code slower as well?

Yes, compiling my own code is also slower, but I've seen this since forever for the same stuff compiled via clang on OSX/Linux vs Windows. I just started to accept it as some weird clang oddity ;)

I haven't installed / activated emscripten SDKs so often in the past on Windows though, so I didn't notice this as much as now.

On Friday, 31 May 2019 04:35:01 UTC+2, Alon Zakai wrote:

About compiling libc which takes so long - is compiling your own code slower as well?

On Thu, May 30, 2019 at 10:54 AM Floh <flo...@gmail.com> wrote:

Would be interesting to see in a fresh install what happens when building a hello world on windows, where the output isn't hidden.

It's libc which takes so long:

cache:INFO: generating system library: libc.bc... (this will be cached in...

--
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 emscripten-disc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/c678df7b-5330-4170-8e65-11c35a1d96b2%40googlegroups.com.
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 emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/e2632bd3-67cf-4364-b6c1-424faaae8be3%40googlegroups.com.

Floh

unread,

Jun 1, 2019, 5:48:03 AM6/1/19

to emscripten-discuss

So far I blamed clang's low speed on Windows to a poor disc IO implementation, and/or NTFS having bad performance with many small IO tasks. But without having real proof ;)

But I've seen similar behaviour in Subversion, where checking out a repository with many small files was up to 10x slower on Windows than on a Linux VM running in the same Windows instance, doing the same checkout to the same disc, but in the VM's Linux filesystem mapped to a single NTFS file.

On Friday, 31 May 2019 19:24:51 UTC+2, Alon Zakai wrote:

Thanks for the info, interesting.

I doublechecked and we do build LLVM in release mode, on Windows and elsewhere. We do build with assertions on all platforms, which is something we can perhaps remove for speed, but it is useful.

Another possible issue is that we use Python multiprocess code to compile libraries (so we use all cores), and I've heard it's slower on windows for various reasons. Perhaps there is something faster? I opened https://github.com/emscripten-core/emscripten/issues/8719

- Alon

On Fri, May 31, 2019 at 12:39 AM Floh <flo...@gmail.com> wrote:

> About compiling libc which takes so long - is compiling your own code slower as well?

Yes, compiling my own code is also slower, but I've seen this since forever for the same stuff compiled via clang on OSX/Linux vs Windows. I just started to accept it as some weird clang oddity ;)

I haven't installed / activated emscripten SDKs so often in the past on Windows though, so I didn't notice this as much as now.

On Friday, 31 May 2019 04:35:01 UTC+2, Alon Zakai wrote:

About compiling libc which takes so long - is compiling your own code slower as well?

On Thu, May 30, 2019 at 10:54 AM Floh <flo...@gmail.com> wrote:

Would be interesting to see in a fresh install what happens when building a hello world on windows, where the output isn't hidden.

It's libc which takes so long:

cache:INFO: generating system library: libc.bc... (this will be cached in...

--
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 emscripten-discuss+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/c678df7b-5330-4170-8e65-11c35a1d96b2%40googlegroups.com.
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 emscripten-discuss+unsub...@googlegroups.com.

Patrik Weiskircher

unread,

Jun 5, 2019, 3:59:03 PM6/5/19

to emscripten-discuss

Hey Alon!

I have a question. We currently have our CI setup to compile specific versions that we define (currently we're running on `1.38.31`) using `emsdk install sdk-tag-${VERSION}-64bit`. We're currently running into a little problem after updating one of our dependencies and I figured I should just simply try out the latest version and hope it'll work. But it doesn't seem like we can do a `emsdk install sdk-tag-1.38.33-64bit` anymore - it says the version doesn't exist.

Is this intended like this and from now on only `latest` is supported? This would be a little problematic for us as we really would like to pin down our versions (we previously had trouble with new versions introducing new bugs).

Thanks for all your work, we all at PSPDFKit really appreciate it :)

Patrik

Gabriel Cuvillier

unread,

Jun 5, 2019, 4:50:55 PM6/5/19

to emscripte...@googlegroups.com

It look like things have changed a bit recently.

Actually, you can know the unique identifier of the last precompiled SDK available in the file "emscripten-releases-tags.txt" file (after issuing "emsdk update-tags" commands)

On my side the contents is:

{
"latest": "1.38.33",
"releases": {
"1.38.33": "3b8cff670e9233a6623563add831647e8689a86b" // this is the unique identifier
}
}

Then with that info I can do:

./emsdk install sdk-releases-upstream-<the_unique_identifier>-64bit

This will install the 1.38.33. This is not very convenient I think, but it works

Gabriel

--
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 emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/04241de6-3244-4c6f-b9ce-064d790815c6%40googlegroups.com.

Patrik Weiskircher

unread,

Jun 5, 2019, 5:09:43 PM6/5/19

to emscripten-discuss

Ah, that'll already solve my problem. Doesn't have to be pretty, just want to be able to specify a specific version. Thank you so much!

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

Alon Zakai

unread,

Jun 5, 2019, 5:11:22 PM6/5/19

to emscripte...@googlegroups.com

Sorry about this, looks like a bug in our migration to the new build infrastructure!

Specifically, we forgot to support "-tag-" in the SDK version names (so it would work without "-tag-").

I opened https://github.com/emscripten-core/emsdk/pull/267 to fix this.

- Alon

--
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 emscripten-disc...@googlegroups.com.

Gabriel Cuvillier

unread,

Jun 5, 2019, 5:11:53 PM6/5/19

to emscripte...@googlegroups.com

Note that I am not sure if we have to use

sdk-releases-upstream-<the_unique_identifier>-64bit

or

sdk-releases-fastcomp-<the_unique_identifier>-64bit

I don't get exactly what is the difference between the two

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/45a0a10c-35ce-4ac8-bb3f-8e9627bf0390%40googlegroups.com.

Alon Zakai

unread,

Jun 5, 2019, 5:15:33 PM6/5/19

to emscripte...@googlegroups.com

In general, you can just do

emsdk install 1.38.34

(or emsdk install latest gets the latest version). That installs it with fastcomp, the current default backend. If you do

emsdk install 1.38.34-upstream

Then it gets the LLVM upstream wasm backend instead. We'll be switching to it by default soon, and will have a larger announcement. Basically we want to stabilize the migration to the new CI first.

- Alon

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/04241de6-3244-4c6f-b9ce-064d790815c6%40googlegroups.com.
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 emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/45a0a10c-35ce-4ac8-bb3f-8e9627bf0390%40googlegroups.com.
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 emscripten-disc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/48a943aa-9768-6337-aa9a-1e22f3262265%40gmail.com.

Patrik Weiskircher

unread,

Jun 5, 2019, 5:19:22 PM6/5/19

to emscripte...@googlegroups.com

This is very good to know, thank you! We will probably just use that going forward.

I was mostly confused because I also tried `./emsdk list` and it didn’t show me the `1.38.33` or `1.38.34`.

But all of this explain everything pretty well! Thank you again for your quick help!

- Patrik

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/fo0W09OYYfk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRnyqZn7jjmTY2aPZNcYqpb3fSSomtGdRUO6vc-rj2Hgw%40mail.gmail.com.

Alon Zakai

unread,

Jun 5, 2019, 5:20:54 PM6/5/19

to emscripte...@googlegroups.com

Good point, thanks, we should update emsdk list. I'll look into that.

- Alon

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/D139BD38-8652-4FAD-A7E7-7C3D4118773D%40pspdfkit.com.

Gabriel Cuvillier

unread,

Jun 5, 2019, 5:34:36 PM6/5/19

to emscripte...@googlegroups.com

Ok, good to know about the upcoming LLVM backend !

I did a few tests of that new backend with the Doom 3 port. Except for EMTEPRETER which is not supported (oops, too bad. I can no more yield to the browser during the long loading screens!), everything else run fine.

I did not noticed significant runtime performance improvement though, but I guess it is because the real bottleneck in D3wasm lies in the GL=>WebGL glue code (or somewhere else, but not in the "pure" wasm binary).

It look like the compilation/link is faster, but maybe that's me.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRnyqZn7jjmTY2aPZNcYqpb3fSSomtGdRUO6vc-rj2Hgw%40mail.gmail.com.

Alon Zakai

unread,

Jun 5, 2019, 5:44:40 PM6/5/19

to emscripte...@googlegroups.com

Thanks, good to know Doom 3 works!

I'll be working on an emterpreter replacement soon, that will work with the wasm backend.

Compilation should be much faster in incremental builds specifically, since it won't recompile all the bitcode (object files contain compiled wasm now)..

- Alon

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/beae7d48-bc9b-ba27-0966-7a30d77868f2%40gmail.com.

Gabriel Cuvillier

unread,

Jun 5, 2019, 5:55:02 PM6/5/19

to emscripte...@googlegroups.com

Oops, sorry, there is issues in fact with the new LLVM backend ! (NB: I made a mistake by compiling/running the fastcomp version of D3, and not the LLVM version).

So the error happens at link stage, with the following output:

error: undefined symbol: g$SIMDProcessorerror: undefined symbol: g$_ZN11idHashIndex13INVALID_INDEXEerror: undefined symbol: g$_ZN5idLib10cvarSystemEerror: undefined symbol: g$_ZN5idLib10fileSystemEerror: undefined symbol: g$_ZN5idLib3sysEerror: undefined symbol: g$_ZN5idLib6commonEerror: undefined symbol: g$_ZN6idCVar10staticVarsEerror: undefined symbol: g$_ZN6idMatX7tempPtrEerror: undefined symbol: g$_ZN6idMath10SQRT_THREEEerror: undefined symbol: g$_ZN6idMath11FLT_EPSILONEerror: undefined symbol: g$_ZN6idMath11SQRT_1OVER2Eerror: undefined symbol: g$_ZN6idMath12ONEFOURTH_PIEerror: undefined symbol: g$_ZN6idMath2PIEerror: undefined symbol: g$_ZN6idMath5iSqrtEerror: undefined symbol: g$_ZN6idMath6TWO_PIEerror: undefined symbol: g$_ZN6idMath7HALF_PIEerror: undefined symbol: g$_ZN6idMath8INFINITYEerror: undefined symbol: g$_ZN6idMath9M_DEG2RADEerror: undefined symbol: g$_ZN6idMath9M_RAD2DEGEerror: undefined symbol: g$_ZN6idVecX7tempPtrEerror: undefined symbol: g$_ZN6idVecX9tempIndexEerror: undefined symbol: g$_ZTV14idSIMD_Genericerror: undefined symbol: g$commonerror: undefined symbol: g$cvarSystemerror: undefined symbol: g$mat3_identityerror: undefined symbol: g$vec3_originerror: undefined symbol: __memory_baseerror: undefined symbol: __table_base

Most of the undefined symbols are global variables or constants in D3 code. I am not sure what is the root cause of the problem.

However, "__table_base" and "__memory_base" undefined symbols looks quite suspect in my opinion. Any hints about where to look ?

Alon Zakai

unread,

Jun 5, 2019, 6:08:35 PM6/5/19

to emscripte...@googlegroups.com

Does this use dynamic linking?

Either way this is very possibly relevant to sbc100's work. Please open a github issue and cc him.

- Alon

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/652ae7a5-4405-2d77-2ceb-a5d208a9dd33%40gmail.com.

Reply all

Reply to author

Forward