https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106102
--- Comment #3 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
Aha, that makes sense.
In this case include chain is:
- c++tools/resolver.cc
-> c++tools/resolver.h
-> libcody/cody.hh
-> libstdc++-v3/include/memory
-> libstdc++-v3/include/bits/shared_ptr.h
-> ...
-> libstdc++-v3/include/x86_64-unknown-linux-musl/bits/gthr-default.h
-> musl-1.2.3-dev/include/pthread.h
-> musl-1.2.3-dev/include/sched.h [uses calloc()]
AFAIU libstdc++-v3/include are all user-facing libraries and are expected to
include system headers like <pthread.h>.
It's a bit worrying that resolver.cc depends on <pthread.h> in such an indirect
way.
Would it be fair to say "system.h" needs to include <memory> for this case and
be done with it?
Does gcc do any system header wrapping by chance to minimize such leaks? I'm
only asking because I noticed musl has different include order from glibc:
https://github.com/NixOS/nixpkgs/issues/142066#issuecomment-1159568114. I tried
to make include order alone closer to glibc and it did not fix the issue.
