Problemcase: The current version of UPX, as delivered by Fedora 30 is not able to pack most ELF executables. Simply grab a random subset of executables from bin, or sbin and try packing them with UPX. You end up getting pack exceptions thrown out. Somehow the bin format might have changed, which now causes UPX to go mad on half of the binaries. It would be nice to get an update or report to upstream.
UPX will refuse to pack binaries that are too small. What are some of the exception reasons that you see aside from that?
Well the size of the files are usually sizes, that UPX used to pack. Some files work and most don't work anymore. Most of the time I see this with files, that are compiled with gcc (under Fedora, using Fedora packages). [root@localhost sbin]# ls -l zerofree -rwxr-xr-x 1 root root 16488 Jul 16 00:00 zerofree [root@localhost sbin]# upx zerofree Ultimate Packer for eXecutables Copyright (C) 1996 - 2018 UPX 3.95 Markus Oberhumer, Laszlo Molnar & John Reiser Aug 26th 2018 File size Ratio Format Name -------------------- ------ ----------- ----------- upx: zerofree: NotCompressibleException Packed 1 file: 0 ok, 1 error. [root@localhost sbin]# Usually I would say that UPX will crunch up that file to 5-7k of total size. I use UPX under x86_64 Fedora 30 by the way. Zerofree and UPX are Fedora 30 packages and just mentioned as an example here.
When I build zerofree from source, UPX will still not compress it. When I try to compress another, larger, Fedora built binary that's 141k, it compresses to 38k. It looks like the binaries you're trying to compress are already too small.
This has never been the case before. I've been using UPX for years now for the same set of files over and over again. It's even part of some semi automated processes to pack the binaries. UPX never complains about "too little" or "too big". You can feed it a 2000bytes file and it attempts packing it and if the result is x < 2000 bytes then the compression is valid. 20000 bytes is definately NOT a barrier for successful compression. There seems to be something else that is wrong. I also don't belive that a "NotCompressibleException" is a valid return for "not being able to compress because the file is too little to compress". It's more something like some procedure is wrong and therefore it freaks out. As said: I've been using UPX for years and my files have grown over years rather than getting smaller. Therefore this behaviour is irritating. UPX used to pack even smaller files without issues. I therefore believe that something else must have changed. GCC, different hunk headers, other relocations, some other minor stuff in code generation that causes UPX to freak out.
(In reply to Gwyn Ciesla from comment #3) > When I build zerofree from source, UPX will still not compress it. Try building it with clang rather than gcc. That's exactly what I did here today. Compiling some stuff with clang rather than gcc and everything clang compiled got perfectly packed with UPX. So there are two situations that may cause the issue: 1) something changed inside gcc that causes it to generate newish executables that 2) UPX can not deal with So either gcc is not binary compatible anymore or UPX is incapable dealing with the changes that has shown up with new versions of gcc.
I can't get it to work by compiling upx with clang. Since gcc is currently the mandated default compiler, I think this is something that should be reported agains t upx upstream. I've done that.
Thanks for reporting this to upstream. What I indented to say is this: Compile zerofree (as an example) with clang rather than gcc. Compiled zerofree with gcc will not pack if UPX has been issued on it Compiled zerofree with clang will pack if UPX has been issued on it This is most likely repeatable with any other program that fails packing using UPX when compiled with newer gcc.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still waiting for an update of UPX. Upstream is working on devel but still no release...
FEDORA-2020-964d8afe00 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-964d8afe00
FEDORA-EPEL-2020-65b0469bde has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-65b0469bde
FEDORA-2020-eea50da7d5 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-eea50da7d5
FEDORA-2020-964d8afe00 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-964d8afe00` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-964d8afe00 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-eea50da7d5 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-eea50da7d5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-eea50da7d5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2020-65b0469bde has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-65b0469bde See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2020-9afbd7a546 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-9afbd7a546 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-eea50da7d5 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-964d8afe00 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2020-65b0469bde has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2020-9afbd7a546 has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.