Re: Recommendations for strip(1)? Was: gdb: "No line number info...."
Re: Recommendations for strip(1)? Was: gdb: "No line number info...."
- Subject: Re: Recommendations for strip(1)? Was: gdb: "No line number info...."
- From: Jerry Krinock <email@hidden>
- Date: Tue, 18 Aug 2009 16:04:32 -0700
On 2009 Aug 16, at 08:40, Alastair Houghton wrote:
We pretty much just run strip with no options.
Thanks, Alastair. My script strips loadable bundle, auxiliary
executable, and private frameworks in addition to stripping the main
executable. I realize that stripping frameworks probably can't do
very much, but for whatever reason, that's what I do.
No options is fine for the main and auxiliary executables, but for
loadable bundles and private frameworks I had to use the -x option;
otherwise the app will crash on launch. The -x option is apparently
equivalent to setting the Strip Style = "Non-Global Symbols", which is
what I have used for stripping my private frameworks in Xcode. I say
"apparently" because I could not determine this from reading man
strip(1)! Instead, I reverse-engineered by watching the strip(1) call
in the Build Transcript in Xcode with various Strip Style settings.
Stripping a main executable reduced its size from 2.4 MB to 1.7 MB,
and comparing the results of running otool -toIVv on the stripped and
unstripped versions I can see that the symbols labels in the assembly
code are gone, so I believe it's working as expected.
One thing I don't like about stripping outside of Xcode now is that
now I've got to re-test the stripped version, just before shipping, in
order to make sure that stripping, for example, a framework, didn't
hide any symbols that should have been exported. Arghh.
If anyone wants to demonstrate the problem, I put together a Steps To
Reproduce [1]. The reader who suspects that this problem may already
solved in their "shiny" version of Xcode is encouraged to try it ;)
I haven't thought this all through, but possibly the only way for
Apple to solve this problem is to eliminate the feature of Xcode to
strip products. I realize it does warn you, but warning of a problem
is just not good enough.
There is one fly in the ointment though; if you're using the Leopard
linker and you are targeting 10.3, because the Leopard linker
doesn't mark the .objc_class_name_ symbols as weak (unlike previous
versions), you need to keep them or your otherwise 10.3-compatible
program won't run on 10.3.
The fix is to do something like
nm <path-to-executable> | sed -n 's/[0-9a-f]* S \
(\.objc_class_name_.*\)/\1/p' > "$TEMP_DIR/symbols-to-keep"
strip -s "$TEMP_DIR/symbols-to-keep" <path-to-executable>
rather than just plain
strip <path-to-executable>
Obviously if you don't care about 10.3, you don't need to bother
with this complication.
Interesting. It looks a little different, but I wonder if this is why
my app would no longer run on 10.3 after an update about a year ago.
I'm not going back there now, though -- after spending a day trying to
fix it, I gave up and dropped support for 10.3.
[1] Steps To Reproduce
Activate Xcode
In menu File > New Project > Cocoa app
call it "Junker"
Inspect Target
Search in Build Settings for "Strip"
Check on:
Deployment Postprocessing
Strip Debug Symbols During Copy
Strip Linked Product
Dead Code Stripping
Search in Build Settings for "DWARF"
Set Debug Information Format to DWARF with dSYM File
View the Build Results pane
Build. No warnings or errors.
Activate Finder, navigate to the Debug Build directory
Delete the Junker.app.dSYM file which was just produced
Reactivate Xcode
Build again
Expected Result: No warnings or errors
Actual Result: In Build results, in GenerateDSYMFile,
warning: no debug symbols in executable (-arch i386)
_______________________________________________
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