Strange big size only of Linux x64 executable

[avra]

I generate executables for Windows 32/64 and Linux 32/64 from the same project, using the exact same settings for each build from fpcupdeluxe installed cross compiler on Windows 10 64-bit and Lazarus 1.8.1 with FPC 3.0.5.  Here is the executable size table:

ct2laz-i386-win32.exe	2.5 MB
ct2laz-i386-linux	2.6 MB
ct2laz-x86_64-win64.exe	3.4 MB
ct2laz-x86_64-linux	6.1 MB   <<<

I would not expect to see such dramatic size increase on Linux 64-bit. Besides fpcupdeluxe cross compiler, I have also tested with native repo Lazarus 1.8 / FPC 3.0.4 on Manjaro 64-bit, and executable size is also above 6MB.

May someone please explain why are Linux 64 bit executables this big?

Project source and executables can be found here:
https://bitbucket.org/avra/ct2laz/downloads/

[bytebites]

ct2laz-x86_64-linux is 3.8 MB on Manjaro 64-bit without debug info.

[avra]

ct2laz-x86_64-linux is 3.8 MB on Manjaro 64-bit without debug info.

Debug info is included in all cases, so all platforms would have smaller executable size when debug info is excluded. This is not the usual "how to get the smallest executable size" problem. Instead, it is "why do I get such increased size when all executables are built from the same project using the same settings". The only explanation I could think of could be that Linux 64-bit debug info is drastically bigger compared to anything else, but I would like to hear why - if that is the case, or the real reason - if clues were leading me on the wrong track.

[taazz]

1) You can easily test if the difference is the debug info by selecting the "use external gdb debug symbols file".
2) aren't integers (memory addresses cpu registers, bus etc) 64bit instead of 32bits ee double in size? But the question is, is that enough for the size change you see?

[avra]

1) You can easily test if the difference is the debug info by selecting the "use external gdb debug symbols file".

Already set in the project. Executable size (this time with trunk on Manjaro64) is 6.4 MB and external gdb is 19 MB. With debug info off I get executable size 3.4 MB, and GDB is of course not generated.

2) aren't integers (memory addresses cpu registers, bus etc) 64bit instead of 32bits ee double in size? But the question is, is that enough for the size change you see?

No. That explains why Win32 to Win64 grows from 2.5 MB to 3.4 MB, but it does not explain why Lin32 to Lin64 grows from 2.6 MB to 6.1 MB. Following that logic I would expect Lin64 to be less then 4MB, but it is not. It is much bigger.

[Josh]

Hi

I dont do Linux, but on MAC using strip in terminal reduces the size even when compiled in release mode with no debug, not sure if same is true with linux.

[dbannon]

josh said -

but on MAC using strip in terminal reduces the size

Well, Josh, you are right, it almost halved the size of my app !  6411704 became 3460140 bytes. All debugging off and smart linking on.

But no, it made no difference on the same app on Linux, which comes in at about 4meg.

(will have to start stripping in my build script, thanks for that !)

David

[avra]

using strip in terminal reduces the size even when compiled in release mode with no debug

I am aware of the ways to reduce executable size, but this is not about it. This is about comparing executables compiled from the same project, with the same compile options, where Win32, Win64 and Lin32 executables have expected size, while Lin64 executable has big unexpected size. Lin64 should not be twice the size of Win64.

[Thaddy]

using strip in terminal reduces the size even when compiled in release mode with no debug

I am aware of the ways to reduce executable size, but this is not about it. This is about comparing executables compiled from the same project, with the same compile options, where Win32, Win64 and Lin32 executables have expected size, while Lin64 executable has big unexpected size. Lin64 should not be twice the size of Win64.

Yes, but may be it escaped you that the difference in size before and after stripping is a valid measure for the amount of bloat that gets actually removed. That's a very good indicator it seems to me.... If stripping removes a lot, the cause is the debug platform infrastructure.
I am rather amazed that you did not follow that logic...Watson... Also note that -CX -XXs seems to remove a bit more than calling strip does: about 300k. I get ~3.8 on Debian Stretch X86_64 after stripping with both methods. That seems consistent with others here. I also took the trouble to compile the lot using WPO and was able to get ~2.4 but WPO is a lot of work, I know.

[molly]

In addition to Thaddy's answer: use readelf to inspect. How do you know for sure there isn't a static library linked in for you that is simply bloated.

The strip is indeed a very good indicator and rules out some other things like difference in compiler optimization for specific target, non optimal binutils etc.

[marcov]

If the binary is still big after stripping, probably you are building with a release/snapshot that was not built with smartlinking.

[Thaddy]

If the binary is still big after stripping, probably you are building with a release/snapshot that was not built with smartlinking.

Avra's code refers to *before* stripping and uses as much as possible ceteris paribus. He wants to know why and what causes the size difference. Comparing stripped and non-stripped is a strong indicator.

[avra]

Thanks for the input. I will do my strip/smartlink/readelf homework when I get home and let you know about the results.

I still don't get it how could something extra end up only in Lin64 executable, but I will do my best to stay open for all ideas since this really bugs me. Hopefully there will be light at the end of this tunnel.

[dbannon]

At risk of clouding the issue with facts, here are the sizes for my project, tomboy-ng, all built with all debug off.

4349840 Feb 20 21:01 tomboy-ng64      --- Linux64
3310060 Feb 20 21:01 tomboy-ng32      --- Linux32
3013632 Feb 20 20:57 tomboy-ng32.exe
4182528 Feb 20 20:56 tomboy-ng64.exe
6411704, stripped to 3460140 Mac 32bit, carbon

I applied strip to them all, no difference on windows and Linux. (Wow, strip did not complain about being pointed to a windows binary!)

So, yes, mine show same pattern but not by same margin.

David

[avra]

here are the sizes for my project

Thank you, David. If my evening tests show similar pattern, then it might turn out that Lin64 debug info brings unexpected size bloat to executable. Much bigger then on Win64 platform. We'll see...