300947 - Use ld -dead_strip for Camino

Status: RESOLVED FIXED

(Camino Graveyard :: General, enhancement)

Description

[Hiro]

Strip is not executed in build of Camino now. 
And "-dead_strip" to which Fix is done with bug300047 is not executed in build
of Camino. 

If strip is done with Camino of a dynamic link, it becomes the following sizes. 

$ls -l Camino.app/Contents/MacOS/Camino 
-rwxr-xr-x  1 sek  sek  937992 16  7 01:45 Camino.app/Contents/MacOS/Camino*
$strip Camino.app/Contents/MacOS/Camino 
$ls -l Camino.app/Contents/MacOS/Camino 
-rwxr-xr-x  1 sek  sek  755808 16  7 04:09 Camino.app/Contents/MacOS/Camino*

Comment 1

[Simon Fraser [no longer active]]

We want to keep some symbols so that stack traces are intelligible.

Comment 2

[Hiro]

(In reply to comment #1)
> We want to keep some symbols so that stack traces are intelligible.

In official build, the "--enable-strip" option is not specified. 
But I think that it should do "--enable-strip" when this option is specified
with mozconfig. 

Comment 3

[Mark Mentovai]

This should be as simple as adding DEAD_CODE_STRIPPING to the build settings. 
Possibly also PRESERVE_DEAD_CODE_INITS_AND_TERMS, which maps to ld
-no_dead_strip_inits_and_terms.  The core didn't take that option, although
maybe it should have?  Time will tell.

Downrev (<1.5) Xcodes should ignore the settings, but I just upgraded my last
1.1 installation to 1.5 so I can't test it easily.

As Simon said, we can't just strip outright in DeploymentSymbols or Development.
 Deployment should already be symbol-stripped, although not dead-stripped.

Comment 4

[Chris Lawson (gone)]

How about those of us who are doing our own custom builds and don't really give
a crap about stack traces? ;) If someone can point me toward a coherent tutorial
for doing this, I'm all ears. Figuratively, of course.

cl

Comment 5

[Mark Mentovai]

Attachment: Strip dead code from non-debug builds

This seems to drop 1.5MB from the static executable and 0.5MB from the download
package.  I'm not pushing it on anyone (yet).

Comment 6

[Samuel Sidler (old account; do not CC)]

Mark, is this something we should include in 1.0? It seems a drop in download size is a Good Thing(tm).

Comment 7

[Mark Mentovai]

The toolchain on the system that produces official builds isn't new enough to support -dead_strip.  If it looks like there's a chance at getting that upgraded soon, we can think about this for 1.0.

Comment 8

[Samuel Sidler (old account; do not CC)]

Based on comment 7, I'm targeting for 1.0, however, this will probably get pushed to 1.1 as I doubt the systems will get upgraded before then.

Comment 9

[Samuel Sidler (old account; do not CC)]

Pushing...

Comment 10

[Mark Mentovai]

We should do this to alleviate some of the weight burden of universal packages.  I'll dust this patch off and retest.

Comment 11

[Mark Mentovai]

(Whatever hypothetical build system produces a universal will support DEAD_CODE_STRIPPING.)

Comment 12

[Mark Mentovai]

Comment on attachment 189509 [details] [diff] [review]
Strip dead code from non-debug builds

Still applies, still works.

When -Wl,-dead_strip (DEAD_CODE_STRIPPING) alone is on, and when it is on in conjunction with -Wl,-no_dead_strip_inits_and_terms (PRESERVE_DEAD_CODE_INITS_AND_TERMS), byte-for-byte identical output is produced.

-Wl,-dead_strip is currently enabled in the core where the build tools support it, and non-Xcode-built apps are fully linked with dead code stripping.  (Bug 300047.)  No problems reported there.

The numbers I quoted in comment 5 may have been relative to no dead stripping in the core.  Still, this will save some additional space, but the numbers I just did show that this change alone will only be worth about 200kB in a universal dmg.

This shouldn't affect pre-Xcode 1.5 builds.

Comment 13

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 189509 [details] [diff] [review]
Strip dead code from non-debug builds

sr=pink

Comment 14

[Mark Mentovai]

Checked in on trunk, 1_8, and 1_8_0.  The tools on the machines that currently produce official nightlies aren't new enough for this to make a difference.