Resulting binary is very large in size

[d4rky-pl]

The project built with ruby-packer fork with Ruby 3.1 weighs 26 MB.
The same project built using tebako takes 133 MB.

Both were built using the same Ubuntu 20 on Semaphore CI.

Comparing ldd result, the only thing that pops out is with debug_info

ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=1e2206d3f5281378abb25bf64d6c88ab1c24f181, for GNU/Linux 3.2.0, with debug_info, not stripped

vs

ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=abeb394be690f772e96bcd5377ca15e9ce39b4c9, for GNU/Linux 3.2.0, not stripped

I remember ruby-packer had the same issue in the past and they managed to fix it after I reported it but I don't know what the fix was and if it's feasible for this project.

[ronaldtse]

Thank you @d4rky-pl for the report. I'm sure @maxirmx would be happy to investigate such practical usability problems...

[d4rky-pl]

Some additional context:

• tested both with current stable and with the RC4 gem from Tebako fails to build if bundler version is different than in Gemfile.lock #164, both were affected
• built both binary versions at least twice on fresh CI machines (and for Mac also locally) to ensure it's not a user error (for ex. accidentally including large unnecessary files)
• only linux version was large (133 MB), Mac version is 29 MB
• source_filesystem from --tebako-extract is 54MB for Mac and 58MB for Linux so it's not the filesystem that is swole, something's fishy is going on with the binary itself.

If it's any help, I ran both the previous ruby-packer built and tebako built version of the tool throught bloaty and got this result:

# ruby-packer one
    FILE SIZE        VM SIZE
 --------------  --------------
  56.3%  14.6Mi  58.7%  14.6Mi    .data
  15.8%  4.09Mi  16.4%  4.09Mi    .text
  15.2%  3.93Mi  15.8%  3.93Mi    .rodata
   2.9%   761Ki   3.0%   761Ki    .eh_frame
   2.6%   698Ki   0.0%       0    .symtab
   1.8%   491Ki   0.0%       0    .strtab
   1.7%   456Ki   1.8%   456Ki    .rela.dyn
   1.1%   297Ki   1.2%   296Ki    .data.rel.ro
   0.8%   225Ki   0.9%   225Ki    .dynsym
   0.7%   178Ki   0.7%   178Ki    .dynstr
   0.6%   160Ki   0.6%   159Ki    .eh_frame_hdr
   0.0%       0   0.5%   123Ki    .bss
   0.3%  76.1Ki   0.3%  76.0Ki    .gnu.hash
   0.1%  18.9Ki   0.1%  18.8Ki    .gnu.version
   0.0%  9.95Ki   0.0%  9.89Ki    .rela.plt
   0.0%  6.67Ki   0.0%  6.61Ki    .plt
   0.0%  5.51Ki   0.0%       0    [Unmapped]
   0.0%  3.88Ki   0.0%  3.81Ki    .got
   0.0%  2.82Ki   0.0%  1.39Ki    [17 Others]
   0.0%  1.32Ki   0.0%  1.32Ki    [LOAD #3 [RX]]
   0.0%     738   0.0%     738    [LOAD #2 [R]]
 100.0%  26.0Mi 100.0%  24.9Mi    TOTAL

# tebako one
    FILE SIZE        VM SIZE
 --------------  --------------
  25.9%  34.4Mi   0.0%       0    .debug_info
  23.8%  31.6Mi   0.0%       0    .debug_loc
  12.2%  16.2Mi  47.8%  16.2Mi    .rodata
   8.7%  11.6Mi   0.0%       0    .debug_str
   8.0%  10.7Mi  31.6%  10.7Mi    .text
   7.7%  10.2Mi   0.0%       0    .debug_ranges
   6.9%  9.12Mi   0.0%       0    .debug_line
   0.0%       0   8.4%  2.84Mi    .bss
   1.2%  1.62Mi   0.0%       0    .debug_macro
   1.0%  1.31Mi   3.9%  1.31Mi    .eh_frame
   1.0%  1.30Mi   0.0%       0    .strtab
   0.8%  1.02Mi   0.0%       0    .symtab
   0.6%   842Ki   0.0%       0    .debug_abbrev
   0.6%   791Ki   2.3%   790Ki    .dynstr
   0.5%   648Ki   1.9%   648Ki    .rela.dyn
   0.3%   469Ki   1.4%   469Ki    .dynsym
   0.3%   385Ki   1.1%   385Ki    .data.rel.ro
   0.2%   239Ki   0.7%   239Ki    .eh_frame_hdr
   0.1%   197Ki   0.5%   187Ki    [28 Others]
   0.1%   156Ki   0.5%   156Ki    .gnu.hash
   0.1%  68.9Ki   0.0%       0    .debug_aranges
 100.0%   132Mi 100.0%  33.8Mi    TOTAL

[d4rky-pl]

Running the binary through strip --strip-debug reduces the size back to 34 MB

[maxirmx]

Thank you @d4rky-pl
In our 'home' project we run strip in the makefile that calls tebako press instead of building the executable correctly.
We were lacking a good reviewer all these years :)