[Test-Announce] Fedora 19 Beta Release Candidate 3 (RC3) Available Now!

drago01 drago01 at gmail.com
Wed May 22 20:24:51 UTC 2013


On Wed, May 22, 2013 at 10:12 PM, John Reiser <jreiser at bitwagon.com> wrote:
> On 05/22/2013 12:04 PM, Clemens Eisserer wrote:
>> As UPX requires executeables to be decompressed during startup (and
>> furthermore does not support ELF shared libraries),
>
> An executable main program which has been compressed by UPX
> *can* use ELF shared libraries, and nearly all programs on Linux
> that are compressed by UPX *do* use shared libraries.
> The execution-time difference between a compressed and a never-
> compressed program is that the Linux kernel loads the PT_INTERP for
> execve() of a regular program, while the UPX runtime stub loads the PT_INTERP
> for a compressed program.  With respect to byte values, there is essentially
> no difference in the memory image of the process.
>
> On a few platforms (including Linux i386 and x86_64) UPX also can
> compress a shared library itself.  You don't get any actual sharing
> of execution-time pages, but storage space in the filesystem is less.
> Compression is not as tight as with a main program, because in a shared
> library only instructions can be compressed: not symbol tables, not .data,
> etc, because these are needed by ld-linux to perform relocation
> which happens before UPX can gain control (which it does via DT_INIT.)
>
>> its not a sane
>> option for a distribution.
>
> It depends on the desired goals.  On distribution media, .rpm packages
> are compressed using xz (lzma2), and the space saved by xz compression
> often is similar to that saved by UPX.  Once installed, the UPX compression
> saves storage space in the filesystem at the cost of no sharing:
> not among multiple simultaneous processes, nor demand paged between
> the filesystem and process memory space.

Which means you'd be better off with file system level compression.


More information about the test mailing list