UPX compression broken for Windows native images produced with 22.x

[axelfontaine]

Describe the issue
See upx/upx#559
And #4051 (comment)

as originally reported by @joerg-wille

I face the exact same issue as well.

[rubyFeedback]

Would be kind of cool to generate binaries for windows, from linux as such, too. :D (A bit like the libui project came up with cross-platform native GUI).
(For me upx works very well on linux; then again most everything in regards to compiling something works better for me on linux. Sorry for the semi-off topic pass-by comment here.)

[david-sitsky]

Hi - I have been hit by this exact issue with GraalVM 22.0.0.2 Java 11 CE on Windows 10. The upx/upx#559 issue describes some workarounds for changes in the GraalVM source code. For an end-user, are there any command-line arguments to native-image which will disable the use of WindowsImageHeapProviderFeature? Are there any other workarounds?

[david-sitsky]

I can confirm using 7zip to remove the com/oracle/svm/core/windows/WindowsImageHeapProviderFeature.class entry within the lib/svm/builder/svm.jar file fixes my issue. It would be nice if this can be solved in the official distribution though.

[sanshengshui]

I have been hit by this exact issue with GraalVM 22.1.0 Java 11 CE on Windows10.

[sebthom]

We are also hitting this issue.

@pejovica @peter-hofer you developed/approved PR #4051 which breaks the compatibility with apparently any kind of exe compression as explained here upx/upx#559 (comment) would be great to get your feedback on this issue. @fernando-valdez does not seem to be active on github so I wonder why he got this issue assigned. Is anyone actively developing graalvm actually monitoring/aware of this issue?

[ArloL]

Removing WindowsImageHeapProviderFeature does not work for 22.3.0 since the code was moved to WindowsFeature with 020e5ed.

I unsuccessfully tried removing WindowsImageHeapProvider.class and WindowsFeature.class. Any other ideas?

[ikappaki]

Hi @fernando-valdez,

You appear to be assigned to this issue, woudl it be possible to provide us with an indication whether this is likely to be looked at or perhaps suggest otherwise? We are currently stuck on older graalvm versions on MS-Windows waiting for a resolution on this issue.

Thanks

[markus-oberhumer]

While investigating UPX issues upx/upx#559 and upx/upx#670 we noticed that sometimes using a low compression level actually makes the compressed exe work.

Could you try if using upx -1 or upx -2 makes any difference in your case?

[sadaaithal]

@markus-oberhumer I can confirm that both upx -1 and upx -2 works for me. Without the flag, the compressed exe just fails with ERROR CODE 193

[theotherp]

For me upx -1 does not work (and neither does upx -2.

[oubidar-Abderrahim]

If this issue is still relevant in the latest GraalVM versions, please create a new issue for it and follow the template provided. Thank you

[BullyWiiPlaza]

If this issue is still relevant in the latest GraalVM versions, please create a new issue for it and follow the template provided. Thank you

Hello, I used GraalVM Runtime Environment GraalVM CE 21.0.2+13.1 (build 21.0.2+13-jvmci-23.1-b30) from here with upx 4.2.2 and the issue persisted. Why do we need a new issue if this one can be re-opened?

[sean-scott-lr]

I am unable to use upx with a graal native image on OSX aarch as well. ( no level from 1 to best work )
GraalVM CE 21.0.2+13.1
upx 4.1.1

echo $?
127