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 ? file icon 0002-Simplify-OS-X-build-and-default-to-clang.patch [^] (3,083 bytes) 2013-04-06 05:23 [Show Content]
? file icon 0001-Autodetect-current-OS-X-compiler.patch [^] (2,808 bytes) 2013-05-20 19:15 [Show Content]

- Relationships
related to 0006661resolvedwheals Potion of experience crashes when compiled with OS X gcc 
has duplicate 0006049resolvedmumra Xcode project files outdated; fail in OS X 10.8 

-  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

- Issue History
Date Modified Username Field Change
2013-04-06 05:23 HenryFlower New Issue
2013-04-06 05:23 HenryFlower File Added: 0002-Simplify-OS-X-build-and-default-to-clang.patch
2013-04-07 13:09 KiloByte Note Added: 0022175
2013-04-07 13:28 KiloByte Note Added: 0022176
2013-04-08 00:28 HenryFlower Note Added: 0022182
2013-04-09 18:17 KiloByte Note Added: 0022224
2013-05-10 04:42 mumra Relationship added has duplicate 0006049
2013-05-10 05:23 mumra Relationship added related to 0006661
2013-05-20 19:14 HenryFlower Note Added: 0022715
2013-05-20 19:15 HenryFlower File Added: 0001-Autodetect-current-OS-X-compiler.patch
2014-11-19 02:17 wheals Status new => assigned
2014-11-19 02:17 wheals Assigned To => PleasingFungus
2014-11-19 03:07 gammafunk Assigned To PleasingFungus => gammafunk


Mantis 1.1.8[^]
Copyright © 2000 - 2009 Mantis Group
Powered by Mantis Bugtracker