Skip to content

Support -no-pthread linking flag #20720

Closed

Description

@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.

Activity

  1. sbc100 commented on Nov 15, 2023

    @sbc100
    Collaborator

    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.

  2. sbc100 commented on Nov 15, 2023

    @sbc100
    Collaborator

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

  3. added a commit that references this issue on Nov 15, 2023
    2882174
  4. RReverser commented on Nov 15, 2023

    @RReverser
    CollaboratorAuthor

    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.

  5. sbc100 commented on Nov 15, 2023

    @sbc100
    Collaborator

    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

  6. sbc100 commented on Nov 15, 2023

    @sbc100
    Collaborator

    Indeed:

    $ gcc -pthread -fno-pthread ~/test//hello.c
    cc1: warning: command-line option ‘-fno-pthread’ is valid for Modula-2 but not for C
    
  7. RReverser commented on Nov 15, 2023

    @RReverser
    CollaboratorAuthor

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

  8. RReverser commented on Nov 15, 2023

    @RReverser
    CollaboratorAuthor

    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?

  9. sbc100 commented on Nov 15, 2023

    @sbc100
    Collaborator

    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.

  10. added a commit that references this issue on Nov 15, 2023
    5b6bf91
  11. RReverser commented on Nov 15, 2023

    @RReverser
    CollaboratorAuthor

    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.

  12. sbc100 commented on Aug 15, 2026

    @sbc100
    Collaborator

    @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

  13. sbc100 commented on Aug 15, 2026

    @sbc100
    Collaborator

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

  14. sbc100 commented on Aug 15, 2026

    @sbc100
    Collaborator

    FWIW I don't think -pthread + -no-pthread ever really worked because at compile time the generic clang driver would always pass only -pthread onto the cc1 (compiler) process: https://github.com/llvm/llvm-project/blob/22eba47a1c4533e9383a422edd29d46d903a43a4/clang/lib/Driver/ToolChains/Clang.cpp#L7348

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions