This program would be just the ticket for getting more mileage
out of my embedded PowerPC linux card's flash ram storage...
but it appears that PowerPC executables are not supported. Any
chance of support for PowerPC executables being added soon?
(my project uses the 2.4 kernel, fwiw)
Kernel packing rocks
The unstable version 1.90 supports kernel packing - this is excellent for single-disc distributions where every k counts.
My kernel decreased in size 20% after upx, and bear in mind that bzImage kernels are in fact compressed with gzip *already* - so it actually beat the existing compression by quite a big margin.
The kernel still boots fine, in fact quicker than it did before.
magic file patch
here's a patch for your magic file (usually /usr/share/magic) to allow file(1) to do simple recognition of UPX compressed executables.
with this patch, running file on a UPX compressed executable you get the following (example) output:
$ file ./gimp
./gimp: ELF 32-bit LSB executable, UPX compressed, Intel 80386, version 1, statically linked, stripped
# apply this patch to /usr/share/magic to allow file(1) to have simple
# recognition of UPX (http://wildsau.idv.uni-linz.ac.at/mfx/upx.html)
# compressed executables
# do (with permissions to write to magic [eg. as root]):
# cp upx.magic.patch /usr/share && cd /usr/share && patch < upx.magic.patch
*** magic.old Sat May 8 04:49:47 1999
--- magic Thu May 13 18:02:18 1999
*** 1351,1356 ****
--- 1351,1358 ----
# What're the correct byte orders for the nCUBE and the Fujitsu VPP500?
# updated by Daniel Quinlan (email@example.com)
+ # UPX (http://wildsau.idv.uni-linz.ac.at/mfx/upx.html) support added
+ # by Jay Johnston (firstname.lastname@example.org)
0 string \177ELF ELF
>4 byte 0 invalid class
>4 byte 1 32-bit
*** 1360,1365 ****
--- 1362,1368 ----
>>16 leshort 0 no file type,
>>16 leshort 1 relocatable,
>>16 leshort 2 executable,
+ >>>154 string UPX UPX compressed,
>>16 leshort 3 shared object,
# Core handling from Peter Tobias
# corrections by Christian 'Dr. Disk' Hechelmann
To quote your description of UPX on Freshmeat (see the top of this page) and at the top of your documentation for UPX:
"Your executables [when compressed with UPX] suffer no memory overhead or other drawbacks"
While UPX excels at its function, it does create drawbacks for the executables it compresses. I was just clarifying that for those looking at the freshmeat description of UPX (using the comments section for what it's there for).
Furthermore, UPX is a closed-source program, so the only way one in the Linux community can help others in regards to UPX's drawbacks is to spread the knowledge of those drawbacks (as opposed to helping to solve them as one would do if the program was Open Source and gpl'd).
Re: damn smooth, but some does have some problems...
To quote the documentation:
- `ldd' and `size' won't show anything useful because all they
see is the statically linked stub.
damn smooth, but some does have some problems...
damn! this util is amazing!!! it does exactly what it says...and real well:
$ cp gimp gimp.upx
$ upx gimp.upx
Ultimate Packer for eXecutables
Copyright (C) 1996, 1997, 1998, 1999
UPX v0.71 Markus F.X.J. Oberhumer & Laszlo Molnar Apr 19th 1999
File size Ratio Format Name
------------------- ------ ----------- -----------
1252148 -> 513408 41.00% linux/i386 gimp.upx
Packed 1 file.
$ ls -fl gimp gimp.upx
-rwxr-xr-x 1 jajohnst users 1252148 Apr 21 23:23 gimp
-rwxr-xr-x 1 jajohnst users 513408 Apr 24 13:56 gimp.upx
and there's no noticeable lag in the app starting up.
curiously, though, upx (apparently) turns a dynamically linked app into a statically linked one:
$ file ./gimp
./gimp: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked, stripped
$ file ./gimp.upx
./gimp.upx: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, stripped
...but it doesn't really:
$ mv /usr/lib/libgtk-1.2.so.0 /usr/lib/libgtk-1.2.so.0.bak
./gimp.upx: error in loading shared libraries
libgtk-1.2.so.0: cannot open shared object file: No such file or directory
so, what all means is that the executable is still a dynamically linked executable, but as far as the system tools are concerned it is a statically linked one:
$ ldd ./gimp.upx
not a dynamic executable
...and that kinda sucks.
An open, cross-platform journaling program.
A scientific plotting package.