build with pthreads always includes library_webgl.js

[niklasf]

Example invocation:

em++ -s USE_PTHREADS=1 tests/pthread/test_pthread_clock_drift.cpp

Does not use any graphics, but output a.out.js contains

var GL={counter:1,buffers:[],programs:[],framebuffers:[],renderbuffers:[],textures:[],uniforms:[],shaders:[],

and so on.

Not eliminated when using -O3 or even --closure 1.

[juj]

This is a known current limitation, unfortunately the pthreads proxying mechanism adds dependencies to other libraries (GL is one of them), that we don't currently build variations of to get them stripped away.

[juj]

If you'd like to strip this away manually, edit src/library_pthread.c and remove anything related to webgl there (and probably also canvas if you don't need that), and then do emcc --clear-cache and rebuild the project. Not sure if that is enough, but probably a good start.

[niklasf]

Thanks. In my application the following hack reduces generated js from 36K to 32K (-O3 --closure 1):

diff --git a/system/lib/pthread/library_pthread.c b/system/lib/pthread/library_pthread.c
index 7811167ed..717246828 100644
--- a/system/lib/pthread/library_pthread.c
+++ b/system/lib/pthread/library_pthread.c
@@ -218,15 +218,17 @@ static void _do_call(em_queued_call* q) {
       q->returnValue.i =
         pthread_create(q->args[0].vp, q->args[1].vp, q->args[2].vp, q->args[3].vp);
 #endif
       break;
+#if 0
     case EM_PROXIED_CREATE_CONTEXT:
       q->returnValue.i = emscripten_webgl_create_context(q->args[0].cp, q->args[1].vp);
       break;
     case EM_PROXIED_RESIZE_OFFSCREENCANVAS:
       q->returnValue.i =
         emscripten_set_canvas_element_size(q->args[0].cp, q->args[1].i, q->args[2].i);
       break;
+#endif
     case EM_PROXIED_JS_FUNCTION:
       q->returnValue.d =
         emscripten_receive_on_main_thread_js((int)q->functionPtr, q->args[0].i, &q->args[1].d);
       break;

[niklasf]

The only other remaining large unused function is strftime. Is that another part of this issue or something else?

[juj]

Hmm, that sounds like something else. Off the top of my head I think pthreads should not be pulling in strftime (although maybe via some convoluted dependency chain it does end up happening)

[kripken]

The strftime issue does seem unrelated, I don't see any references to it from pthreads code, and it doesn't show up with building hello world with pthreads. Do you have a testcase @niklasf that shows it is included even though it's not used?

[niklasf]

It's happening in https://github.com/niklasf/stockfish.wasm, but so far I haven't been able to reduce it to a smaller test case. I can confirm it's not included in tests/pthread/test_pthread_clock_drift.cpp, for example.

Meanwhile, since I am now patching emscripten anyway, as above, I just replaced the implementation with a call to abort().

[sbc100]

If you want to see why a given symbol is included you can try the -Wl,--trace-symbol=strftime flag. It should say which object file is pulling in the symbol and where its coming from.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

[niklasf]

Still relevant.

[sbc100]

There seem to be two different issues here: GL and strftime.

For the GL issue it sounds like you have a workaround and we have no plans to fix.

For the strftime issue it should like are waiting for a report on adding -Wl,--trace-symbol=strftime which should tell us why your project depends on that symbol.

[niklasf]

Ok, closing the main part (GL) as won'tfix, then. Will reopen the strftime issue if I manage to create a small reproducible example. -Wl,--trace-symbol=strftime unfortunately did not work (no output), even though the symbol is clearly there.