Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Strip x86 code from fat binaries System
Developers are starting to distribute binaries that will run on Intel-based hardware as well as PowerPC Macs. This will add about 30% to the size of the executables. To recover the disk space, you can remove the unneeded code using the command-line program ditto.

For example, suppose Foo.app is a fat application bundle installed on a PowerPC Mac. While logged in as an admin user, you would open a Terminal window and type something like:
ditto --rsrc --arch ppc /Applications/Foo.app /Application/Foo-ppc.app
Now you have a new application called Foo-ppc.app. Test it. If it works, you can delete the original and rename the stripped version. To strip PPC code from binaries on an Intel Mac, you would change --arch ppc to --arch i386 in the above command.

In case it's not obvious, keep in mind that this operation is not reversible. Once you strip the code for a particular architecture from a multi-architecture executable, it will no longer run on that architecture. So keep a backup copy.
    •    
  • Currently 2.29 / 5
  You rated: 2 / 5 (7 votes cast)
 
[34,047 views]  

Strip x86 code from fat binaries | 26 comments | Create New Account
Click here to return to the 'Strip x86 code from fat binaries' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Ouch
Authored by: bedouin on Aug 17, '05 10:22:35AM

Is that 30% inflation rate accurate?



[ Reply to This | # ]
Ouch
Authored by: aamann on Aug 17, '05 12:01:31PM

No, 30% is probably a very pessimistic guess - the additional size depends on the way the program was written and can be as low as only a few kB for several MB apps.

Also, you should probably keep in mind that this might break application updates - don't come screaming back claiming "update xxx broke my system/application" after you have been doing this - developers tend to assume (probably rightfully so!) that the user does not screw with the binary application/package!



[ Reply to This | # ]
Only for the actual binaries
Authored by: llahsram on Aug 17, '05 12:44:08PM

Just to clarify: the only files that see an increase in size are the binaries inside the app bundle. Many of the files in a given app are images, .nib interface files, sounds, configuration, etc., and those won't increase.

The Safari bundle on my machine, for example, is 20 MB. But the actual binary in Safari.app/Contents/MacOS is only 1MB. If this were a Universal binary, this might go up to as much as 2MB -- but that's only a 5% increase (worst case) in the total application size.



[ Reply to This | # ]
Ouch
Authored by: adrianm on Aug 17, '05 03:38:41PM
Unlikely, the actual code bit is usually quite small. Even in the executable file, text, constants, symbols, etc are big; not to mention the images, help, text, video and other bloat that apps usually have.

I'll file this hint under Look at me! I read the ditto man page!

[ Reply to This | # ]

Universal Binaries
Authored by: ktohg on Aug 17, '05 10:49:17AM

This is great for the one time one code model of a system that is not scalable. In other words once your strip the binary it will no longer be universal and hence no longer scalable you will be lock into that architecture and if you upgrade you better hope they have the same chipset.

It kinda the opposite of what Apple it attempting to do with universal binaries. So keep that in mind and make backups. (Then again with the price of hard drive space these days a (guessing) 30% increase isn't too bad.)

Use wisely.



[ Reply to This | # ]
Not scaleable?
Authored by: veloso on Aug 17, '05 04:14:47PM

Stripping x86 code is like stripping languages you don't use (via monolingual).

First, "scaleable" isn't the right word.

Second, the chances that you -aren't- going to reinstall everything when you get that brand-spanking-new osx86 box are low to nonexistent.

Third, why not? 30% may not seem much, but when you've got a 40 or 80 gig drive every little bit helps. Heck, running monolingual removed tens of megabytes of useless junk (uh, language support) from my system.



[ Reply to This | # ]
Universal Binaries
Authored by: smkolins on Aug 19, '05 09:39:12AM

Of course use wisely, but what is not very scalable is bin bloat as one must destribute installations across hundreds or thousands of computers - our images are often approaching 12 GB as is and adding i386 bloat could significantly expand images, and slow down distribution.

I wish Delocalizer would add a de-archer option.

---
= - - -- - - - =
Steven
smkolins@mac.com
http://homepage.mac.com/smkolins
Possess a pure, kindly, and radiant heart!



[ Reply to This | # ]
Why?
Authored by: cmdahler on Aug 17, '05 12:26:35PM

I find it hard to believe that anyone would be so strapped for disk space that they would find this solution necessary. For example, Photoshop CS2, which is a seriously large .app at 84.1MB, would be around 100MB if the 30% size increase prediction holds true. If someone had such limited disk space that they actually needed to strip out that extra 25MB, they've got bigger problems - like the fact that Photoshop probably wouldn't even start up on such a small drive. Ultimately, one could go through an average user's application folder with this program and recover maybe 200 to 500 MB. Yet even if you recovered up to 1G, that's hardly worth either the time or the risk of rendering the application useless and forcing a reinstall.



[ Reply to This | # ]
Why?
Authored by: Rob Best on Aug 17, '05 02:00:30PM

Actually there are some very good reason.
My main two reason is:
Smaller backups
Smaller Disk Images (when creating Disk Images for the purpose of cloning. Smaller the image, faster the clone!)

I also use Delocalizor to remove all non-english languages from application bundles too, saves lots of space (I suspect far more than removing x86 code)



[ Reply to This | # ]
Re: Why?
Authored by: gidds on Aug 17, '05 03:09:28PM
Yes, I remove other language bundles too. (Using my own script.)

But that's different for a couple of reasons. Firstly, size; while many language bundles are small, some apps have lots of 'em making up well over half of their size; whereas for a double-binary, 50% is the absolute most you'd ever save, and it'd usually be much, much less.

And secondly, I'm unlikely to ever want to run any of my apps in Albanian! But it's actually rather likely that I'll want to move to x86 eventually.

Of course, it's up to every Mac user whether they want to thin their binaries, but unless you're certain you'll be sticking to a PPC Mac even when they're extinct, I'd think carefully about trading a small bit of disk space now against major headaches when you come to switch.

---
Andy/

[ Reply to This | # ]

Why?
Authored by: hamarkus on Aug 17, '05 03:30:14PM

My Applications folder is 8 GB, a 30% increase would be 2.4 GB. Still it probably would not be worth the effort, maybe doing it for just a handful of the biggest apps might make sense.

However, for all those people worried about the eventual switch to MacIntels, it would probably be wise if not even right out necessary to do a new install on the MacIntels anyway.

I very much doubt that cloning will work (for that OS 10.4.6 would have to be a fat binary). Reinstalling the OS and then copying the Applications folder is something that might work, but I would not recommend it even now (cloning plus Archive and Install seems like a better solution).



[ Reply to This | # ]
Why?
Authored by: clacz on Aug 17, '05 03:59:42PM

You wouldn't saved anywhere near 2.4 GB on a 8GB application folder. It would be 30% of the executable size, not the entire .app directory. In most applications the executable size in 1/2 to 1/10 the size or less of the entire .app directory. You would probably save closer to 600MB rather then 2.4GB.

If you have games (Warcraft, Diablo ect) or applications like iDVD that have a huge amount of data in the .app package you might only reduce the size on those by a couple percent. iDVD takes 1.5GB, but the executable is only 3.5 MB. You might save 1.5 MB there, and maybe a little more on the frameworks, but those are small. That's about a 1% reduction in size.



[ Reply to This | # ]
Strip x86 code from fat binaries
Authored by: g16l on Aug 17, '05 12:53:18PM

lipo could be a better alternative, see "man lipo"



[ Reply to This | # ]
Strip x86 code from fat binaries
Authored by: JJCortes on Aug 17, '05 01:21:43PM

So, if I understand well, to make some free room you have to erase a portion of universal binaries program and keep a normal copy. That's sounds nice except that you increase the room by 70%, not decreasing by 30%.
:-(



[ Reply to This | # ]
Strip x86 code from fat binaries
Authored by: lincd0 on Aug 17, '05 04:47:04PM

lipo operates on one file at a time. ditto can process a whole directory tree containing multiple executables with one command.

[ Reply to This | # ]

Strip x86 code from fat binaries
Authored by: smkolins on Aug 19, '05 09:48:30AM

nice thought but ditto --arch /dir1 /dir2 flattens out at least the first set of folder in /dir1 into /dir2.

Suggestions?

---
= - - -- - - - =
Steven
smkolins@mac.com
http://homepage.mac.com/smkolins
Possess a pure, kindly, and radiant heart!



[ Reply to This | # ]
Ditto Command Arguements
Authored by: Gigacorpse on Aug 17, '05 02:57:09PM

While to can still use the --rsrc argument with Ditto, there is no need to do so with Tiger as it is now the default setting (unless you have the enviromental variable DITTONORSRC set). There is also a --norsrc switch as well.

You can read the Ditto manpage here.



[ Reply to This | # ]
Strip x86 code from fat binaries
Authored by: boredzo on Aug 17, '05 03:15:02PM

the lipo solutions are:

  • lipo -thin ppc
  • lipo -remove i386

both of these should result in a ppc executable. I have not tested this, however; I'm just going by the manpage.



[ Reply to This | # ]
Strip x86 code from fat binaries
Authored by: _merlin on Aug 17, '05 08:01:16PM
The difference is lip -thin ppc will remove i386 and ppc64 if present (i.e. also killing any G5-optimised version) while lipo -remove i386 will leave ppc and ppc64, and any other architectures that are present.

[ Reply to This | # ]
The true savings are probably lower -
Authored by: acdha on Aug 17, '05 05:50:06PM

Note that the space savings are only from the executable files, not the entire application bundle. For apps like Keynote or iDVD this frequently isn't noticeable since so much of the size is due to platform-independent resources (graphics, localizations, etc.).



[ Reply to This | # ]
Backup?
Authored by: joerick on Aug 19, '05 07:17:00AM
So keep a backup copy.
Doesn't that defeat the point of saving hard disk space?

[ Reply to This | # ]
Strip x86 code from fat binaries
Authored by: smkolins on Aug 19, '05 09:40:30AM

I wonder what programs are already being destributed with i386 code....

---
= - - -- - - - =
Steven
smkolins@mac.com
http://homepage.mac.com/smkolins
Possess a pure, kindly, and radiant heart!



[ Reply to This | # ]
Strip x86 code from fat binaries
Authored by: smkolins on Aug 19, '05 09:53:52AM

I just processed my Applications folder and trimmed about 8 MB out of 3.4GB. Not much there so far but I'm surprised to find any.

---
= - - -- - - - =
Steven
smkolins[at->]maccom
http://homepage.mac.com/smkolins
Possess a pure, kindly, and radiant heart!



[ Reply to This | # ]
Strip x86 code from fat binaries
Authored by: smkolins on Aug 19, '05 09:57:04AM

here's another implication - you may also trim down the spotlight index by trimming out the code not needed...

And when you are running on i386 you may equally need to trim out the PPC code, eh?

I do hope not too many updaters will trip on missing code <sigh> but I suppose it could be worked around by fresh install, fresh patches, then trim and then copy out via ARD or similar.... might actually be worth trustworthy in anycase....

---
= - - -- - - - =
Steven
smkolins[at->]maccom
http://homepage.mac.com/smkolins
Possess a pure, kindly, and radiant heart!



[ Reply to This | # ]
Strip x86 code from fat binaries
Authored by: David Allen on Jan 11, '06 10:39:37PM

I've noticed that the newest version of Monolingual now removes Architecture. I have been fearful of using it because I don't want to f--- up my machine.

The archs listed are ppc, ppc750, ppc7400, ppc7450, ppc970, ppc64, ppc970-64 and i386.

So if one has a PCC 750 (G3) one could safely remove all the others?

---
David Austin Allen
Monterrey, NL, MX



[ Reply to This | # ]
Strip x86 code from fat binaries
Authored by: Frungi on May 20, '06 06:00:10PM

That's a very good question that I want an answer to… if I have a G4.5 (ppc7450), would I need the ppc and/or earlier G4 (ppc7400) archs?



[ Reply to This | # ]