[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 gcc-bugzilla@gcc.gnu.org
Mon Jun 27 12:03:56 GMT 2022


--- 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

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.

More information about the Gcc-bugs mailing list