Update build.rs to be consistent for all Apple targets
briansmith opened this issue · comments
In build.rs, we have things like:
if target.os.as_str() == "macos" {
// ``-gfull`` is required for Darwin's |-dead_strip|.
let _ = c.flag("-gfull");
it isn't clear to me what should happen for TVOS, watchOS, iOS, etc. It seems likely that at least some of them need to be treated consistently with macOS, but it also seems likely that there might be differences. We should fix and document this.
Seems like this is more interested in the fact its using Mach-O then the actual host platform? The executable format, syscalls, ABI, etc are identical between them (with exceptions of things like arm64e) so I'm not aware of a difference ring would need to think about. Similar to what's already been done with MACOS_ABI, maybe this should change to "is darwin like".
I reviewed the build.rs and that appears to be the only such conditional right now.
On documenting, I was intrigued about the odd interaction between Mach-O debug information and dead code stripping. The flag combination looks to be cargoculted into just every kind of C/C++ project (including ring 8 years ago) . Its documented here in a buried Apple changelog:
Before turning on the -dead_strip option your project will first have to be "ported" to work with dead code stripping. This will include changing from -gused (the default for -g) to -gfull and re-compiling all of the objects files being linked into your program with the new compiler from the Mac OS X June 2004 release. Also if your building an executable that loads plugins, which uses symbols from the executable, you will have to make sure the symbols the plugins use are not stripped (by using attribute((used)) or the -exported_symbols_list option). If you are using an export list and building a shared library, or an executable that will be used with ld(1)'s -bundle_loader flag, you need to include the symbols for exception frame information in the export list for your exported C++ symbols. These symbols end with .eh and can be seen with the nm(1) tool.
These internal changelogs seem to indicate it's been a requirement since XCode came into existence based on version numbers, so I suppose Apple's dead code stripping implementation relies on full debug information being available. And that further backs this should be applied to any Darwin target, not just macOS?