Closed coccyx closed 3 years ago
Root cause of this is likely related to upx/upx#298 - @pdugas can you please confirm?
I was able to build UPX from source on an ARM machine and use that to compress the scope
binary from 33M down to 20M. The resulting binary appears to work with some cursory manual testing. Running the full suite of integration tests now.
If this works, my plan is to add UPX as a new contrib and use that to restore the earlier behavior of the build system to compress scope
on both x86 and ARM.
Unit and integration tests all pass on ARM using the compressed scope
binary on ARM and the pre-4.0.0 unreleased UPX built from source. Will get a PR out shortly.
Before we pull the trigger on merging #547 to address this, I think we need to get some consensus on whether we want to use the unreleased version of UPX that's been added as a contrib on that PR.
I see four options here:
scope
binary stays large like it is now.scope
like before but leave the ARM version uncompressed.scope
like before and the 4.x development (unreleased) version of UPX to compress the ARM version.The PR is currently setup for option 4. Anybody have a strong opinion here?
Moving this under 0.7.6 milestone since the PR #547 didn't close by 0.7.4 milestone timing
Direction from @ledbit in stand-up today was to add back compression of the x86 version of scope
using the released version of UPX and leave the ARM version uncompressed. When UPX releases a version for that supports ARM, we can return to compressing the ARM version.
Given the direction above, I'm abandoning the work on the feature/531-upx
branch where we added UPX as a contrib. I will close that PR then open a new one for a new branch that only makes the Makefile changes needed for the simpler approach.
QA INSTRUCTIONS
Do:
On an ubuntu machine:
git clone git@github.com:criblio/appscope
cd appscope
make build
cd bin/linux/x86_64
ls -hl scope
Expect: scope binary is less than 30MB in size
In issue #449 we stopped
upx
compression of the binaries, which has resulted in a bloating of the current binary to 53MB, which is far too large.We need to find a solution to binary size, since we now put multiple copies of the binary and the library into the container which has ballooned to a whopping 218MB: