"Cannot fork" error when building with 3.1.39 (coming from 2.0.34)

[aduermael]

We're trying to update the emsdk to build our application.
We were still using 2.0.34.

We installed 3.1.39 and could build our app without issues. But at runtime, we're getting these logs in the console:

Cannot fork. Function not implemented [52]
FAILED: 279 of 279 unit tests have failed.

It seems to point to that line specifically:

We've been trying to understand that, looked around for similar issues, but we're unfortunately still clueless.

Tried to emcc --clear-cache + flushing build directory.

I don't think fork() used to be allowed either with 2.0.34, and it still works for us when sticking to that version.

[sbc100]

The fork system call certainly never worked in emscripten, and I don't think it ever returned success, even with 2.0.34.

I would imagine that calling fork() would always result in a ENOSYS being returned. It certainly does that today:

emscripten/system/lib/libc/emscripten_libc_stubs.c

Line 169 in 98b618f

weak pid_t fork(void) {

It looks like that stub was created in #15209 which essentially moved the stub from JS code to native code. And that PR was released in 2.0.32.

My advice would be to try to track down where your code is calling fork, and why? And was it somehow not calling fork() in the working build? Or was it somehow ignoring or tolerating the error return code from fork()

[aduermael]

Thanks for this answer @sbc100!
fork is certainly not called in our code, but maybe in one of the few libs we're using.
I'm still surprised 2.0.34 would tolerate it though...

We'll also try to update our HTML/JS shell page, now thinking it might be required.

[sbc100]

Perhaps you can build with -Wl,--trace-symbol=fork to find out where the reference to fork is coming from? You could do that with both 2.0.34 and 3.1.39 to perhaps get some more information.

You might also try bisecting to find out which emscripten release introduced this issue for you: https://emscripten.org/docs/contributing/developers_guide.html#bisecting

[aduermael]

Ok, we found the problem!
With the new SDK, the wrong main function was executed.
Made us realize we were compiling & linking useless test code...
We were actually lucky that it worked with emsdk 2.x.

Thanks for your help anyway @sbc100!