Re: dead-code stripping, pass two...
Re: dead-code stripping, pass two...
- Subject: Re: dead-code stripping, pass two...
- From: Steve Christensen <email@hidden>
- Date: Wed, 17 May 2006 14:39:15 -0700
Well, were I to rant, I'd expect that if you clicked on a dead code
stripping checkbox, then the code would, in fact, be stripped
properly. It shouldn't really matter what the other settings are
since the compiler should always generate enough information for the
linker to be able to tell which bits of code and data are being used
and which aren't.
Or, at least, CW was somehow able to do that... :-)
On May 17, 2006, at 1:51 PM, Allen Cronce wrote:
Hi Steve,
Unfortunately I think the answer is that Xcode dead code stripping
just
doesn't work all that well.
Like you, I just recently I ported a project that produced a 90k
binary
size with CW. The first cut port to Xcode, with dead code stripping
on,
resulted in a 1.6 meg universal binary. I finally was able to get it
down to a mere 600k by adding some strategic conditionals that removed
methods from the compile. But to do this I had to disassemble the
bloated binary to see what dependencies were causing the extra bulk to
be brought in. It was an ugly hack and a ton of work.
Maybe I'm off base here, but I think the problem is that the Xcode
linker is just primitive. It can't seem to shed unused functions
within
an object file. And it can't resolve interdependencies between static
libraries. I don't know, or care, if it's the GCC linker under the
hood.
The fact is that the CW linker was far more sophisticated and
efficient.
My experience is that if you're porting any reasonable size code base
from CW to Xcode, you're going to run into linker problems. In our
case,
we had to completely rework our static library organization. And if we
really care about what code is in or out of our executables, we pretty
much can't use static libraries because the only way to manage the
code
linked in is to use project specific conditionals.
I've ranted about this before, so I'll try to keep it short. But
honestly I think that Apple really did the developer community a
disservice by not providing a decent linker. Because I think a lot
of us
came to rely on the fact that the CW linker handled whatever we
threw at
it and still produced reasonable executables. Take that linker
away, and
you're screwed. I know that our company has wasted, and continues to
waste, tons of man hours on linker related issues.
There's a lot of things to love about Xcode. But the linker is not one
of them.
Rant mode off.
Steve Christensen wrote:
I'd asked about this last month and didn't really receive any
responses, so I figure I should try again just in case.
I have a number of plug-in projects I imported from CodeWarrior to
Xcode as part of making them Universal and all that. They build and
run correctly, but I've noticed that the binary size has grown
considerably more than 2x (in one case going from around 48K in
CodeWarrior to 197K as a UB built by Xcode).
After doing a little more poking around, I found that the problem
appears to be that unused class methods are not being stripped out,
which means that the method code as well as any that they reference,
etc., etc., gets left in the binary. These are not virtual
methods, BTW.
I have dead-code stripping and symbol stripping turned on, as well as
doing an extra post-link strip pass and specifying an exported
symbols
file just to see if that would make a difference. It doesn't.
Is there some magical incantation that I've missed someplace? A known
linker bug? A bug in the CodeWarrior project import process?
_______________________________________________
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