Difference pthreads.library/threads.library and -athread=native (extended)

@all

See topic...

I have
pthreads.library 53.12 (24.05.2020)
from, i think, the latest SDK?
53.11 at least, and an update from somewhere...

and
threads.library 26700 ----rwed 31-May-05 14:42:10
probably v1.4 from Os4Depot.net (http://www.os4depot.net/?function=sho ... library/misc/pthreads.lha)

Do i really need the two?
Is the latter one outdated since?
Why is the latter one called pthreads.library, but threads.library in the package?
Since the SDK provides also the latest includes, should threads.library be even around in the system anymore? (Mix of libraries can lead to hard to track crashes)

Thank you

@Raziel

Since noone else answers this, I'll give it a go. It most Likely started out as threads.library perhaps changes were made which made it even more posix like so to make it more relevant to people they changed the name to pthreads for posix threads... you can check if the headers are similar and the final test is to move the current threads.library to for instance sys:storage and do a soft link from pthreads.library to threads.library and try to run with something that demands threads.library

@beanbandit

Thank you
I've since renamed threads.library so it won't get picked up in any way and I haven't gotten any bad feedback from the programs.
SDK includes have been updated as well and are not using threads.library, as far as I can see...so I guess it's safe to say the os4depot version is obsolete

threads.library is part of an early port of pthreads.

It had issues and was discontinued in favour of pthreads.library, which was rewritten from scratch

However, some software that uses pthreads and hasn't been rebuilt againast the newer version might require threads.library

One example is perl 5.8 (but not later versions) which you might possibly have installed in paralelle with later version of perl if you like playing "Frozen".

It's completely safe to have both threads.library and pthreads.library installed at the same time. (they have different names and won't get confused).

@beanbandit

Quote:

Nice try But threads was always a port of the pthreads API. It's author Thomas Frieden I think, decided to abandon it and replace it with new port reworked from scratch.

Quote:

Yikes! Don't even think about doing that, libraries have different names for good reason! They are not compatable in anyway. Actually ramlib expects the libraries name and filename to match so it might not even load, but if it did it would crash 100%!

@broadblues

Ah, thank you
Well, i deleted it since, if some program starts to complain i know where to look

@all

Extending my original question to -athread=native in compilations.

Are they different or just different approaches to the same goal?

If, for example, i wanted to use the native athreads over pthreads, would that work, or would i have to use pthreads in any way if a program relies on it?

libcurl f.e.
It's the only dependancy that includes pthreads.
What if i instead use -athread=native exclusively and drop pthreads?
Is that possible or will libcurl always rely on it except theres a new version of libcurl compiled without pthreads? (If that is even possible)?

I'm asking because it's a large build and i don't want to waste time only to be stopped after two hours when it won't work.

Thank you

@Raziel

Not really sure what athreads are?

There's no particuar reason not use pthreads of a projects you are using depends on them. It will much simpler than trying to create your own threading system using CreateNewProc() and friends.

@Raziel

-athread switch is to choose the threading model for C++11 concurrency features. If your C++ project is NOT using std::thread and friends, then stick to -athread=single (binary should be smaller). If you need C++11 concurrency features, then you should use -athread=native.

If your project is otherwise depending on pthreads, this switch doesn't change that.

@Capehill
@broadblues

Got it, thank you

If i link with -lpthread should my program use
prhreads.library? If yes how to cause it to?
My program calls threads.library (i do not
directly call it i only yse libpthread.so).

Is it a problem of includes or linkerlib or so lib, that
I use a too old version there?

I would like to go for the new version as the old version
(Threads.library) seems to have bugs but i do not
know how i can make pthreads to use pthreads.library
Instead of threads.library.

If i have to recompile my program to make this change
this is no problem it is not yet released anyways.

Thanks.

Steffen

@TheMagicSN

If you're using libpthread.so then I would have thought you're already using pthreads.library because there is no .so in that archive on OS4Depot (perhaps -lpthread is not finding a .so if the symlink is missing, and using the .a).

But in the case that it's not using pthreads.library, make sure your clib2/newlib libpthread.a hasn't been overwritten by the one on OS4Depot.

If it has been, this is what to do.

Inside SDK_54.16.lha is pthreads-53.12.lha. Extract that to your SDK directory, overwriting what you have. This doesn't contain libpthread.so but a symlink will be created later.

You also need to delete pthread.h from SDK:local/newlib/include and SDK:local/clib2/include. The newer header is in SDK:local/common/include

If you already have a SDK:local/newlib/lib/libpthread.so, it might be the wrong one. Create a soft symlink so SDK:local/newlib/lib/libpthread.so points to SOBJS:libpthread.so. This is how the SDK installer does it.

Check your SOBJS:libpthread.so is the right one. Mine is 162435 bytes with a date of 6th Jan 21.

Thanks. Using libpthreads.so (not sure from where it came but probably from the SDK) fixed the crash issues (at least one source of crash issues, there is another one which is unrelated to pthreads but I think I found a solution there too).

@Steffen
Quote:
As far as i see, our SDK didn't come with libpthreads.so. It comes just with some old pthreads-53.12.lha written by Friedens brothers, which only contain static libpthread.a for clib2 and newlib, but surely no .sobj for.

Now, if you use clib4 (which not official part of SDK for now) instead of newlib, then you just use Andrea's libpthread.so (clib4 have it, yes), which of course more tested and more modern. Then it of course will works better for clib4 apps.

Maybe you simple mess the libpthread.a from newlib with clib4 build, or, maybe if you use clib4 , then libpthread.a may have bug, while libpthread.so not.

I am not sure were i got the so from. But the problems
which i had with the .a are gone with it (no longer uses
threads.library). And i use newlib.

@kas1e

As said by MickJT earlier the SDK doesn't include a libpthread.so because it should already be installed in SOBJS:. Instead the SDK installer just creates a soft link from "SDK:local/newlib/lib/libpthread.so" to "SOBJS:libpthread.so".

@TheMagicSN

If it was using threads.library instead of pthreads.library, and you were using libpthread.a (rather than .so), then it was the wrong libpthread.a too.

Both the .a and .so will use pthreads.library.

The .so is in SOBJS: and comes with OS4.1 (a symlink is made in SDK:local/newlib/lib during the SDK installation). The .a is installed by the SDK installer (from pthreads-53.12.lha).

My guess is that you'd overwritten the .a with the old one on OS4Depot (and if you were using -use-dynld and the .so symlink wasn't there, it would use the .a). Follow my instructions a few posts above and remember to delete the old pthread.h header file (if you have one in clib2/include or newlib/include), because otherwise it won't use the newer one in common/include.

Thanks yes that would explain it. Though i am using a docker image which contains the libpthread.a. I guess when that image was created the wrong lib was used.