How to not use threads?

[tansy]

I have simple question - how to NOT use threads? Mingw keeps linking to `libwinpthread-1.dll' despite me not using threads and not intending to. Also I want to check speed with single processor so I want to know how to avoid it.

In Linux it doesn't link to `libpthreads.so' at all, as I would expect, so it's even stranger.

[mackron]

Most compilers have a bunch libraries that they link to by default. That'll just be one of those defaults with your MinGW distribution. It's got nothing to do with any stb_* libraries since there aren't any build scripts here that would even define link libraries.

[tansy]

Most compilers have a bunch libraries that they link to by default

That's not how it works.

If I compile and link hello-world.c it wont link to `libwinpthread-1.dll', or any other pthread library for that matter. Neither I don't use.

$ cat <<EOF > hi.c
#include <stdio.h>
int main()
{
printf("Hi!\n");
return 0;
}
EOF
$ gcc -o hi.exe hi.c
$ objdump -x hi.exe | grep "DLL Name:"
        DLL Name: KERNEL32.dll
        DLL Name: msvcrt.dll

#### versus

$ cat <<EOF > hi-stb.c
#define STB_IMAGE_IMPLEMENTATION
#include "stb_image.h"
#include "stb_image_write.h"

int main()
{
    int w, h, ch;
    char* if1;
    stbi_info(if1, &w, &h, &ch);
    return 0;
}
EOF

$ gcc -o hi-stb.exe -I../../lib/stb/stb hi-stb.c
$ objdump -x hi-stb.exe | grep "DLL Name:"
        DLL Name: KERNEL32.dll
        DLL Name: msvcrt.dll
        DLL Name: libwinpthread-1.dll
        DLL Name: USER32.dll

In Linux the result will be bit different

$ gcc -o hi hi.c
$ objdump -x hi | grep lib | grep .so
  NEEDED               libc.so.6
  required from libc.so.6:

$ gcc -o hi-stb hi-stb.c
$ objdump -x hi-stb | grep lib | grep .so
  NEEDED               libm.so.6
  NEEDED               libc.so.6
  required from libm.so.6:
  required from libc.so.6:

There is something regarding pthreads in the library that makes think compiler it uses pthreads. And that think is preprocessed in windows and not in *nix.

[mackron]

Again, it's not stb_* that's explicitly including that library. It's your compiler that's deciding that it's needed. In any case, since you've now decided to actually tell us that it's stb_image that you're using rather than expecting us read your mind, try using #define STBI_NO_THREAD_LOCALS. It might be that your compiler needs a library to achieve that functionality.

[tansy]

Ok. I found `STBI_THREAD_LOCAL' to look promising and after defining it it didn't link libpthread. It seems to work.

So the question to dev - is that the right way to control it?

[tansy]

The problem is not that we don't know what STBI_THREAD_LOCAL does

I, as a user, don't know. There is nothing in documentation, nor in a header/s either.

It was a guess. I grepped all header for `thread' and that's what I found. I tried it and it seems to work.
Then I asked: "is that a way to control threads?"
And I didn't get an answer.

the problem is that we don't know what thread locals do on MinGW

So what it/they do in linux/*nix?

[tansy]

if you do something and it makes it works in MinGW, that's good enough for us

So, the question remains:

is `STBI_THREAD_LOCAL' a way to in/exclude threads in STB? Let's say in Linux/*nix, leaving aside MinGW.

[rygorous]

It has nothing to do with "including/excluding threads", it's about whether to flag certain global variables (mostly the error string) as thread-local or not. On Linux and other targets this does not influence which libs you need to link with. MinGW as ever seems to be the odd one out.

[tansy]

So, although it would it's not the right thing to do.
Is that what it means?

[nothings]

The flag is a safety valve in case something unexpected goes wrong. The flag was not INTENDED to control any library requirements. We wouldn't expect it to affect library requirements. But sure, it might do so under MinGW, which is, in our experience, most likely to be inconsistent with everything else. We don't know. We don't develop with MinGW, and don't intend to do so. You are on your own.

In other words, "sure? it's mingw, so whatever works".

[tansy]

For the benefit of everyone reading this or having the problem I made a ticket report in mingw-w64. Maybe they will do something with it. Hopefully.