Support -no-pthread linking flag

[RReverser]

Apparently Clang has a -no-pthread option. It's not very useful on most platforms (and is even broken on some llvm/llvm-project#69363) but supporting it in Emscripten could help solve a common issue with complex build system where some autoconf + libtool scripts add -pthread to the list of linker flags and they end up propagated all the way to the top linker invocation with no easy way to remove it.

If you know that the library only uses pthread condvars and similar APIs that don't really need multi-threading support, you could link with the Emscripten's pthread stub, and still get a usable, smaller, and, in some cases, even faster, Wasm binary. However, currently there is no way to selectively disable just the pthreads during the linking phase and ask for the stub instead.

Being able to do $(LD) $(LDFLAGS) -no-pthread where -no-pthread overrides a former -pthread flag would solve this issue elegantly.

[sbc100]

Hm.. first I've heard of that flag. I wonder my clang added that given that gcc doesn't support it.

I agree that its seems reasonable for emcc to support this.

[sbc100]

Looks like it dates back to 2015: http://reviews.llvm.org/D11087

[RReverser]

I wonder my clang added that given that gcc doesn't support it.

In gcc there is -fno-pthread which I assume should be the same? Not sure though.

[sbc100]

I wonder my clang added that given that gcc doesn't support it.

In gcc there is -fno-pthread which I assume should be the same? Not sure though.

Do you have a reference for that? The only thing I would find the refers to that is for the Modula-2 frontend: https://gcc.gnu.org/onlinedocs/gm2/Compiler-options.html

[sbc100]

Indeed:

$ gcc -pthread -fno-pthread ~/test//hello.c
cc1: warning: command-line option ‘-fno-pthread’ is valid for Modula-2 but not for C

[RReverser]

Ah. I just saw it exists, but haven't tried.

[RReverser]

There is also a reference to mingw64 gcc in the issue you linked:

When compiling mingw-w64 gcc provides us with a -no-pthreads option because it is linked in by default
If we want to build mingw-w64 with clang and not gcc we must not link to pthreads
clang currently fails at building mingw-w64 because it errors out for unknown argument.

So I guess it exists in some variants of GCC but not others?

[sbc100]

There is also a reference to mingw64 gcc in the issue you linked:

When compiling mingw-w64 gcc provides us with a -no-pthreads option because it is linked in by default
If we want to build mingw-w64 with clang and not gcc we must not link to pthreads
clang currently fails at building mingw-w64 because it errors out for unknown argument.

So I guess it exists in some variants of GCC but not others?

Yes, -no-pthreads that is. Not -fno-pthread.

[RReverser]

Yes, -no-pthreads that is. Not -fno-pthread.

Then it does seem surprising that Clang chose a different spelling. Oh well, either one is fine by me.

Thanks again for adding it! Already have a project in mind where it could be useful.

[sbc100]

@RReverser, sorry to re-open this old issue but I releazed the we were incorrectly handling this upstream in clang and removed the explictly support here llvm/llvm-project#216378. Clang will still accept it but its simply a no-op on all platforms. It doesn't actually disable pthreads, its just the pthreads are already disable by default, it was only added upstream for compat with mingw64, and it never actually did anything in clang.

So I'm proposing to have it do the same thing in emscripten too, i.e. do nothing

[sbc100]

PR to remove explict support and basically do what clang does and ignore the flag: #27546