#41408 closed defect (fixed)
xorg-cf-files/imake/xcb: Concat3() macro failure w/ clang with Xcode 5
Reported by: | Ionic (Mihai Moldovan) | Owned by: | jmroot (Joshua Root) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.2.1 |
Keywords: | Cc: | MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), cooljeanius (Eric Gallager), jeremyhu (Jeremy Huddleston Sequoia), ryandesign (Ryan Carsten Schmidt) | |
Port: | xorg-cf-files imake |
Description
Now that Mavericks dropped llvm-gcc support, we're left with clang not supporting "traditional CPP", thus making the Concat3 macro fail.
This bug came by when compiling xcb, but is actually triggered by xorg-cf-files, thus setting port to that value.
Also see #31504
Attachments (4)
Change History (16)
Changed 11 years ago by Ionic (Mihai Moldovan)
comment:1 Changed 11 years ago by larryv (Lawrence Velázquez)
Keywords: | xcb xorg-cf-files imake Mavericks removed |
---|---|
Summary: | xorg-cf-files/imake/xcb: Concat3() macro failure w/ clang on 10.9 → xorg-cf-files/imake/xcb: Concat3() macro failure w/ clang with Xcode 5 |
This is technically because of Xcode 5, not Mavericks per se. I suspect you’d also see it on a Mountain Lion system with a fresh Xcode 5 installation.
comment:2 Changed 11 years ago by Ionic (Mihai Moldovan)
True. I've been probably rebuilding xcb for the first time with Xcode 5.
Changed 11 years ago by qbarnes (Quentin Barnes)
Attachment: | xcb-Portfile.patch added |
---|
Patchfile for xcb's Portfile to work around the xmkmf problem
comment:5 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
I don't think the solution we want is to blacklist clang.
comment:6 Changed 10 years ago by jmroot (Joshua Root)
Cc: | jeremyhu@… added |
---|---|
Port: | imake added |
I think this should do it.
Changed 10 years ago by jmroot (Joshua Root)
Attachment: | Portfile.diff added |
---|
Changed 10 years ago by jmroot (Joshua Root)
Attachment: | patch-imakemdep.h.diff added |
---|
comment:7 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Owner: | changed from macports-tickets@… to jmr@… |
---|
Looks fine to me. Go ahead and push.
comment:8 Changed 10 years ago by jmroot (Joshua Root)
Unfortunately this also requires a change to base: r125859
comment:9 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign@… added |
---|
Not if we move imake/xmkmf support to a portgroup as I'm proposing on the mailing list: https://lists.macosforge.org/pipermail/macports-dev/2014-September/028142.html .
I suggest that the llvm-gcc42 or gcc49 dependency belongs in such a portgroup instead of in the imake port, since the installed version of Xcode, and thus the necessity for a gcc dependency, might change after imake is installed, and/or the user might get a binary of imake from our packages server built using a different version of Xcode than the user has.
comment:10 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Note that I'm in favor of removing all ports in question. If a port is still using imake, it is seriously under-maintained and doesn't really belong in a modern distribution.
comment:11 Changed 10 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | new → closed |
r126419 (using the much more lightweight tradcpp instead).
comment:12 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
I love it! I can go fix the ports that use imake. I'll remove the clang blacklist and add this block:
# Can remove after MacPorts 2.3.2 is released if {${os.platform} eq "darwin" && ${os.major} >= 12} { configure.cpp ${prefix}/bin/tradcpp }
xcb build log