• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: "Fat" debug apps in Xcode.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "Fat" debug apps in Xcode.


  • Subject: Re: "Fat" debug apps in Xcode.
  • From: Scott Tooker <email@hidden>
  • Date: Thu, 16 Mar 2006 11:44:55 -0800


On Mar 15, 2006, at 12:34 PM, Brad Oliver wrote:

I've been working on a lot of our back titles, porting them to Xcode recently, and I've gathered up a number of questions along the way. First up is extremely large debug apps. :-)

By large, I mean we're creating apps that are over a gig in size, and some of which fail to link at all because they're pushing 2 gigs. I've noticed a few things that are relevant. First, the biggest apps are built with several intermediate static libraries that are linked into the final app (this mirrors the builds on MSVC and CodeWarrior). Second, we use precompiled headers quite extensively to speed up the build time.

For one game, one of the subtargets is a static library containing 700 source files. With the precompiled headers on, each .o file is anywhere from 3 to 6 megs in size. When the .a library is created (well, not created in this case), it's 1.6 gigs and we get an error about vm_allocate failing at link time. For some projects that do build and link successfully, our "build" directory can be *9* gigs in size when it contains the debug and release intermediates. (I inadvertently filled up my hard drive the other day this way.)

So it's apparent that the precompiled headers are bulking up and repeating data in each intermediate .o file. What's not apparent is how to stop that. ;-) There is a setting "Separate PCH Symbols" (GCC_ENABLE_SYMBOL_SEPARATION) that looks like it is the answer, but the help notes say that it is on by default for everything *but* static libraries. Sure enough, enabling it gives us a build that does not work, although the intermediate .o files are much more reasonable in size.

We have dead-code stripping on, but it seems to not do any stripping when the .a is created, at least for duplicate symbols in the static library. We also have "Only Link In Essential Symbols" turned on, but that doesn't seem to make any difference.

Any tips?

With Xcode 2.2.1, the best solution for now is to turn on the following build settings when building the static library:


"Perform Single-Object Prelink" (GENERATE_MASTER_OBJECT_FILE=YES)
"Level of Debug Symbols" set to "All Symbols" (GCC_DEBUGGING_SYMBOLS=- gfull)


Scott


-- Brad Oliver email@hidden


_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >"Fat" debug apps in Xcode. (From: Brad Oliver <email@hidden>)

  • Prev by Date: Re: One byte bool
  • Next by Date: Re: Why won't Xcode find my framework?
  • Previous by thread: "Fat" debug apps in Xcode.
  • Next by thread: Xcode 2.2.1: Debugger shows truncated stack display
  • Index(es):
    • Date
    • Thread