Opened 3 years ago
Last modified 3 years ago
#64247 assigned defect
openrct2: builds failing for 10.13 and earlier, with macports-libcxx: cyclic dependency errors
Reported by: | mascguy (Christopher Nielsen) | Owned by: | mascguy (Christopher Nielsen) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | kencu (Ken), Tatsh (Andrew Udvare) | |
Port: | openrct2 |
Description
In the interest of providing this port to an expanded set of macOS releases/users - originally it required 10.15 and later - this port was updated to utilize macports-libcxx
.
As for the previous 10.15+ requirement, that's related to use of libcxx features only present in 10.15 and later. That makes it a perfect candidate for macports-libcxx
, which fills that gap. And thus far, the latter works beautifully, based on its use with other ports.
Of note, it's understood that upstream may be dependent upon newer macOS APIs. So it's not yet clear what the floor is, relative to a minimum macOS version for this port. (At least without modifications/patches.)
Nonetheless, at least in local testing, macOS 10.13 does appear to work properly: Not just for the build, but at runtime as well. Confirmed by running with official Roller Coaster Tycoon 2 game files, purchased from GOG.
However, on our buildbots, builds are failing for 10.13 and earlier. And the errors involve potential cyclic dependencies, during header inclusion/consumption.
Here is one example, for 10.13:
openrct2/work/OpenRCT2-0.3.5.1/src/openrct2/platform/Platform.macOS.mm While building module 'std' imported from openrct2/work/OpenRCT2-0.3.5.1/src/openrct2/platform/../Diagnostic.h:12: While building module 'Darwin' imported from /opt/local/include/libcxx/v1/ctype.h:38: In file included from <module-includes>:74: In file included from /opt/local/libexec/llvm-9.0/lib/clang/9.0.1/include/tgmath.h:21: /usr/include/tgmath.h:27:10: fatal error: cyclic dependency in module 'std': std -> Darwin -> std #include <math.h> ^
It's possible that this is a relatively simple issue, perhaps related to compilation arguments. However, more discussion and investigation is needed.
Change History (5)
comment:1 Changed 3 years ago by mascguy (Christopher Nielsen)
Cc: | Tatsh added |
---|
comment:2 follow-up: 4 Changed 3 years ago by kencu (Ken)
comment:3 Changed 3 years ago by Christopher Nielsen <mascguy@…>
comment:4 Changed 3 years ago by mascguy (Christopher Nielsen)
Replying to kencu:
Assuming this is related to c++ modules, as it appears to be, this issue has so far been not trivial to work around.
They make the SDK headers in one place use other headers in that place, ignoring your header include paths.
Ken, while I'm still a bit foggy on the interactions, what is driving the behavior? For example, is it rigid header/path inclusion enforced via the toolchain, which can't be overridden? Or...?
Ultimately I'm just trying to understand where the issue is, and whether it would be feasible for us to sidestep it.
comment:5 Changed 3 years ago by kencu (Ken)
I have this ticket for you to look through:
https://trac.macports.org/ticket/59992
And these two references:
https://stackoverflow.com/questions/22693950/what-exactly-are-c-modules
https://www.modernescpp.com/index.php/c-20-modules
and my admission that my understanding of all this is also not deep and fulfilling...
Assuming this is related to c++ modules, as it appears to be, this issue has so far been not trivial to work around.
They make the SDK headers in one place use other headers in that place, ignoring your header include paths.