Anonymous | Login | 2024-04-25 09:53 CEST |
Main | My View | View Issues | Change Log | Wiki | Tavern | News |
Viewing Issue Simple Details [ Jump to Notes ] [ Wiki ] | [ View Advanced ] [ Issue History ] [ Print ] | |||||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | |||||||
0006882 | [DCSS] Patches | minor | have not tried | 2013-04-06 05:23 | 2014-11-19 03:07 | |||||||
Reporter | HenryFlower | View Status | public | |||||||||
Assigned To | gammafunk | |||||||||||
Priority | normal | Resolution | open | |||||||||
Status | assigned | Product Branch | 0.13 ancient branch | |||||||||
Summary | 0006882: Simplify OS X build and default to clang | |||||||||||
Description |
Xcode has deprecated GCC (see: https://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/WhatsNewXcode/00-Introduction/Introduction.html) [^] The attached patch does four things: 1) Change the make invocation to XCODE=y 2) Default NO_PKGCONFIG and CONTRIB_SDL options for a tiles build 3) Change the default complier to clang/clang++ 4) Add a FORCE_APPLE_GCC option to allow compiling with GCC Building with clang has some additional warnings -- I'll (slowly) work through those warnings to create a clean build with clang, but the warnings are currently harmless. |
|||||||||||
Additional Information | ||||||||||||
Tags | No tags attached. | |||||||||||
Attached Files |
0002-Simplify-OS-X-build-and-default-to-clang.patch [^] (3,083 bytes) 2013-04-06 05:23 [Show Content]
0001-Autodetect-current-OS-X-compiler.patch [^] (2,808 bytes) 2013-05-20 19:15 [Show Content] |
|||||||||||
|
Relationships | |||||||||||
|
Notes | |
(0022175) KiloByte (manager) 2013-04-07 13:09 |
After some thinking, I don't think this is a good idea: * clang is far from parity with gcc, especially in C++. Until quite recently, it couldn't compile Crawl at all (choking on valid C++), and even present versions produce a number of bogus warnings that don't augur well about its correctness. The code generated is also quite a good deal slower: on amd64: Note: 0000020% with clang 3.0, ~4% with clang 3.2, worse on arm. On the other hand, it does pass tests, so using recent clang . * Apple swiftly drops support for past versions of MacOS X from XCode. Since official versions of Crawl still support old Macs, all the way to late powerpc ones, we need to use old XCode. This means, one with non-existant or unusable clang. This said, I think it could be good to detect the compiler at compile time, in an autoconfy way. Or alternatively, trusting the system's default -- ie "cc"/"c++" instead of "gcc"/"g++" could be even better, and simpler. |
(0022176) KiloByte (manager) 2013-04-07 13:28 |
As for warnings, I often rebuild with clang, and I try to keep it warning-clean, bogus or not. Too bad, there's several problematic ones: clang 3.0: * warning: format string is not a string literal (potentially insecure) [-Wformat-security] Note no file or line number! This one is caused by clang getting confused by __attribute__((format printf)) when the format string is a default argument. clang 3.2: * colour.cc:346:25: warning: comparison of constant 128 with expression of type 'element_type' is always true [-Wtautological-constant-out-of-range-compare] ASSERT(colour->type < 128); 128 is certainly in range of int, and that's the type it's implicitly declared as. Clang notices it can harmlessly narrow the type to something smaller, and does so (the C++ standard allows enum storage to be narrowed), yet optimizations are not supposed to change the program's semantics. This assertion could be silenced by an explicit cast, but I'm afraid of it hiding real bugs. * ./menu.h:530:9: warning: private field 'ncols' is not used [-Wunused-private-field] It is used -- just try removing it and see what happens. Unlike "static", "private" fields may be used outside of file scope, in code that implements methods in the struct. I have no idea how to silence this one. These warnings are those that pop up on Debian, it's possible there are others on Mac. |
(0022182) HenryFlower (reporter) 2013-04-08 00:28 |
I think checking if the cc symlinks to gcc vs clang makes sense here. Note that the Xcode gcc front end is very old (4.2.1 vs current 4.8) -- Apple stopped updating when gcc went GPL 3. Performance seems snappier on my system for clang vs. GCC-LLVM. Native GCC 4.7.x might be faster, but it would take some significant doing to get there. There's at least one nasty bug that moving to clang fixes (https://crawl.develz.org/mantis/view.php?id=6661). [^] I have no idea how to fix that one short of changing compliers. Here are the warnings that I see on OS X -- seem pretty similar to the ones you see: In file included from directn.cc:8: ./directn.h:236:10: warning: private field 'may_target_monster' is not used [-Wunused-private-field] bool may_target_monster; main.cc:245:16: warning: unknown attribute 'externally_visible' ignored [-Wattributes] __attribute__((externally_visible)) ^ ./menu.h:530:9: warning: private field 'ncols' is not used [-Wunused-private-field] int ncols, pagesize; ^ output.cc:439:19: warning: private field 'm_change_pos' is not used [-Wunused-private-field] const color_t m_change_pos; ^ tilepick-p.cc:1211:25: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (idx < 0 || idx > tile_player_part_count[p]) ~~~ ^ ~ THere's also some minor issues with the final binary build: clang: warning: argument unused during compilation: '-rdynamic' clang: warning: argument unused during compilation: '-pthread' |
(0022224) KiloByte (manager) 2013-04-09 18:17 |
"externally_visible" was a fault on our side (specifically mine), fixed. I blame the visibility scheme in Unix compilers, this is one of few things Microsoft has done better, by defaulting symbols to "hidden" unless explicitly exported. "private field is not used" is a bug in clang, with no obvious workaround. "unsigned expression < 0" is somewhat ambivalent. I don't know about -rdynamic on Mac, this is needed for backtraces. Do they work in crash dumps regardless? I find the -pthread warning strange, but then, I don't know Macs. It doesn't show up with clang on Debian, at least. |
(0022715) HenryFlower (reporter) 2013-05-20 19:14 |
I did another try at this patch, autodetecting based on whether gcc or clang is linked to cc |
Mantis 1.1.8[^] Copyright © 2000 - 2009 Mantis Group |