RTS doesn't support multiple OS threads

Learn
1

Hello.
I am trying to compile an executable and get the following error at runtime:

<my-executable-name>: user error (RTS doesn't support multiple OS threads (use ghc -threaded when linking))

Here are the GHC options I used to build it (default stack options, and the build is successful):

ghc-options:
  - -threaded
  - -rtsopts
  - -with-rtsopts=-N

The executable uses the following libraries: base, containers, scotty, bytestring, text, brick, regex-base, regex-pcre, array, http-conduit, http-types, http-client, vty. Do you think some of them might not be compatible at runtime? There is no information about that in the docs of these various libraries.

Thanks in advance for your help !

2

Those dependencies shouldn’t be an issue.

Things to confirm:

  1. Where are those ghc-options being set?
  2. How are you running your executable?
1 Like
3

Whether it be stack exec or manual execution through retrieving the executable, I get the same error. The GHC options are in the package.yaml file of this project.

4

And in the generated .cabal file, those ghc-options are seen in the executable section?

5

Yes they are! Both executables (client and server) have an executable section in the cabal file looking like this:

executable ...
  ...
  ghc-options: -threaded -rtsopts -with-rtsopts=-N

Only the library part does not have these options, but this library just contains type declarations that are common to the 2 executables in my project.

6

Since you’re specifying -rtsopts, can you run you start your program with <your-prog> +RTS --info (explained here), and paste the output here?

7

Yes of course! Here is the output:

 [("GHC RTS", "YES")
 ,("GHC version", "8.8.4")
 ,("RTS way", "rts_thr")
 ,("Build platform", "x86_64-apple-darwin")
 ,("Build architecture", "x86_64")
 ,("Build OS", "darwin")
 ,("Build vendor", "apple")
 ,("Host platform", "x86_64-apple-darwin")
 ,("Host architecture", "x86_64")
 ,("Host OS", "darwin")
 ,("Host vendor", "apple")
 ,("Target platform", "x86_64-apple-darwin")
 ,("Target architecture", "x86_64")
 ,("Target OS", "darwin")
 ,("Target vendor", "apple")
 ,("Word size", "64")
 ,("Compiler unregisterised", "NO")
 ,("Tables next to code", "YES")
 ,("Flag -with-rtsopts", "-N")
 ]
8

Alright nothing looks out of the ordinary there. Would you mind making a separate test project that contains:

import Control.Concurrent

main :: IO ()
main = getNumCapabilities >>= print

And making sure it compiles with the same ghc-options you have for your real project, can you run it and see if the same error appears? I’m trying to determine if the source of the problem is your machine, your config, or your deps as you original suspected.

9

It prints 8. Is this the number of cores on the machine? I can still update my project to GitHub so that you do not have to stick to the Discourse asking for precisions. Here is the link. I really want to thank you for your efforts, it is very kind.

10

Great, I’ll try building it myself.

11

I just ran these commands:

$ cd /tmp
$ git clone git@github.com:cloudyhug/major.git
$ cd major
$ cabal build
$ cabal run major-server -- 8888 A B

And that gives no errors.

1 Like
12

Hi. Thanks for helping. I tried with stack exec and stack run and now it works. The raw executable works too… I still don’t understand what I have changed for it to start working…

13

I will probably mark the topic as solved even though I have no explanation, as it started to magically work.
By the way, I see you use cabal and not stack. Is there a specific reason for this? Isn’t stack supposed to be a wrapper around cabal to publish projects more easily?

1 Like
14

Stack has the advantage of a fixed known good package set and better documentation. But that fixed package set has the disadvantage that it is harder to try out other versions or packages that are not included in the set. I’m more a student and hobbyist, so I don’t really care that much about stability and I am already knowledgeable about cabal, so I don’t need the extra documentation. Cabal is also lighter on disk space because dependencies are shared across projects and I think stack rebuilds dependencies for every project (.stack-work is always much larger than dist-newstyle). (Thanks for the correction @fosskers) I also like that cabal is developed by an independent group of open source contributors without commercial incentives and obligations. All in all I think cabal is the best choice for me, but I can understand why other people like stack more.

15

As a minor correction, stack does indeed share dependencies across projects. There’s nothing wrong with cabal, though I’ve always used stack since it offers me a few extra quality-of-life features that I’ve gotten used to over the years.

1 Like