Have IOSurface depend on Libsystem rather than XPC

[toonn]

Describe the bug

The IOSurface framework as defined by the apple-source-releases depends on XPC. This causes redefinition errors because other frameworks get these definitions from Libsystem. There was an attempt to fix it in PR #161561, but this causes build problems due to Libsystem and libc++ being incompatible currently, so it was reverted in PR #162681.

Steps To Reproduce

The first problem:

1. Build something that depends on Libsystem and IOSurface, like mac-notification-sys.

The second problem:

1. Apply the patch having IOSurface depend on Libsystem rather than XPC.
2. Build something depending on IOSurface and libc++, like xcbuild.

Expected behavior

The incompatibility between Libsystem and libc++ should be fixed so we can have IOSurface properly depend on Libsystem without causing problems.

[tjni]

This issue is blocking me, so I started to investigate it, but I need some help.

With PR #161561 applied, I can reproduce the xcbuild build error. By adding some debugging print statements, we can observe that the arguments to clang++ include:

-isystem /nix/store/czzxpxnigp3r0zb4sklwksv5zahsgkdp-libSystem-11.0.0/include
...
-isystem /nix/store/wlp2bii0r52zh2p7bkp84v0jwqj22ya9-libcxx-11.1.0-dev/include/c++/v1

Because libSystem is added to -isystem before libcxx, the cmath file from libcxx includes math.h from libSystem instead of from libcxx, compilation breaks. libcxx needs its own math.h, because it redefines macros such as signbit as functions and then refers to them as such (e.g. ::signbit).

I'm not very experienced with C/C++, so I could use some opinions on how this conflict should be handled. Thank you!

/cc @toonn

[tjni]

Perhaps it would make sense to remove the path to libSystem (in general, the path to glibc) from CPLUS_INCLUDE_PATH in the clang wrapper. Or, alternatively, add libcxx to the beginning of CPLUS_INCLUDE_PATH instead of to the end.

/cc @cmm @Mic92, I saw both of you have worked on resolving these sorts of issues before, and I'd love your thoughts.

[toonn]

Good digging. I'm not sure where the include order is determined. Would changing this order be a fix or would other programs expect libSystem's math.h?

[tjni]

In theory, including libc++'s math.h before libSystem's math.h should be safe, because libc++'s is compatible:

#include_next <math.h>

// redefines some macros from math.h as functions

However, I would be more surprised if something doesn't break after making this change either.

I am trying to dig into this more today, but my lack of experience with debugging and developing in nixpkgs is showing. My plan is to connect to the Matrix channel and ask for some advice there.

[stephank]

I think this can be closed now that #191235 is merged?

[toonn]

Yes, thank you for pointing this out!

Fixed in #191235