[Bug c++/106102] gcc/cp/mapper-resolver.cc fails to build against musl: musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"

[slyfox at gcc dot gnu.org]

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.