I am trying to use golang and have it installed. The project is usingg cgo, which required gcc. Installing gcc installed the libpthread package. However that package did nothing. There is no libpthread anywhere. The .list file for the package is empty. How do I get the library?
It is built-in into musl C library, so the empty libpthread exists mainly for compatibility reasons.
You normally do not need to do anything.
Also for those broken build systems that unconditionally do -lpthread:
1 Like
Yes, I saw the FAQ. It speaks of a libpthread stub that is distributed with musl for compatibility. What I meant when I said the OpenWrt libpthread package was empty was that it was literally empty. There are no distributed files with the libpthread package. There is not even the stub libpthread.a file anywhere on the system.
Why there is a libpthread package that is marked essential and which doesn't even have the musl stubs in it, I cannot fathom. Why have the package at all if the end user has to even make the compatibility stubs?
OpenWrt supports three different libc flavors; musl, glibc and uclibc. The latter two have separate libpthread shared objects. To keep source level dependencies common among the flavors, an empty dummy is added in the musl case.
OpenWrt does not officially support on-target compilation and shipping a .a file for exactly that purpose would be a waste of space, as would be embedding header files or man pages.
So, let me get this straight:
- Building musl builds the pthread compatibility stub library
- OpenWrt goes to the trouble of making a libpthread package for musl so that other dependencies don't have to be changed for musl
- But it was decided that including those stubs which compiling musl built might give people the idea the idea that on-target compilation is supported
- ...and the eight bytes of the stub library file is wasted space.
- ...so to that end someone actually decided to leave the musl libpthread package honest-to-god literally empty
So ten out of ten for sticking to your guns. But sheesh, negative several million out of ten for good sense.
Thanks for the chuckle all the same. 
No, the package predates OpenWrt‘s switch to musl
Development files (.a, .h etc.) are never packaged in OpenWrt, it hasn‘t been specifically decided for this particular case.
Huh? There are no stubs (empty .a) included. Unless you mean the empty package definition. As I wrote above, it predates OpenWrt‘s switch to musl by default. When OpenWrt is compiled with a libc that happens to produce a libpthread.so, the pthread package will include it. In the case of musl, no libpthread.so exists, so the package ends up being empty. Shipping an empty libpthread.a does not happen because a) it would be extra, musl specific logic that does not apply to uclibc or glibc b) no packed software needs an empty libpthread.a archive at runtime c) it is very easy to create that stub for those rare caes where it actually is needed (unsupported on-target compilation of software with broken build systems unconditionally linking -lpthread without adequate checks) d) OpenWrt firmware images never contain development specifc resources
As already explained, this has been done to remain source level compatible, otherwise hundreds of packages would need to be changed from a simple DEPENDS:=+libpthread into DEPENDS:=+USE_GLIBC:libpthread +USE_UCLIBC:libthread and changed again whenever another libc implementation is added.
I did my best to explain the situation but I am not in the mood to listen to snarky remarks just because you‘vevbeen confronted with somethingbbeing different than your expectation.
3 Likes
Let me start this by allowing that I was oversnarky and apologizing for that.
What I meant is this. When musl is built, a stub libpthread compatibility library is built along with everything else - something that musl does, apparently, for improved compatibility. So whatever build system OpenWrt is using to build the musl libc is already actually producing the libpthread stubs in question here.
Right. And what was also explained is that...
Which means with two of them, libpthread is a separate library, and when anyone installs the libpthread package on those devices they will get real libraries on their system.
Which further means that on devices using two of the three supported libc platforms, if someone compiles a program that links against libpthread it will actually compile and link with no errors. But on those who have devices with musl as the libc, someone performing the exact same operation with the exact same set of packages installed will find it fails.
That there was the source of the snark. I go to compile a program which fails on the lack of a library, so I install the library package, find out the package with the library doesn't actually have it, find out the empty stubs which musl distributes aren't even in the package... I think anyone coming at it from the same vector would reach the same level of incredulous "you can't be serious that this is intentional" thinking.
I genuinely apologize for the response, but I stand 100% by my assessment of the decision.