[SOLVED] Linux binaries too big

[Thaddy]

First: the compiler itself does not matter but the RTL and FCL and the FPC packages should...be build with -Cg -Xc -XX -CX and maybe -Xs
Second: Why would you need Forms and Interfaces in a shared library? That is bad practice: It will pull in ALL code, since a shared library will never be able to distinguish what you need.
A simple shared library is a few KB on Linux. Add classes for some Pzazz and it is still under 1 MB. (867 KB on ARM-LINUX.Note it still pulls in ALL of classes)

Code: Pascal  [Select][+][-]

1. library project1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. uses
6.   Classes{, Forms, Interfaces //are bad design!! for a shared library}
7.   { you can add units after this };
8.  
9. begin
10. end.  

The template for a shared library looks plainly stupid for Linux, but also in general.
Sensible programmers won't put any GUI code in a shared library. Unless it IS the shared library, e.g. GTK+ or QT.

[tk]

First: the compiler itself does not matter but the RTL and FCL and the FPC packages should...be build with -Cg -Xc -XX -CX and maybe -Xs

Could you achieve with these options, that the compiled shared library under Linux has similar size as on Windows? I've rebuilt whole FPC (which means compiler+rtl+packages) with options -CX -XX -Xs (options -Cg and -Xc were not accepted and always resulted in misc. compilation errors) then took these options for my project and made Clean+Rebuild. And did not succeed, binary size is still around 3x bigger for a SO than for a DLL.

Second: Why would you need Forms and Interfaces in a shared library? That is bad practice: It will pull in ALL code, since a shared library will never be able to distinguish what you need.

I have good reasons why to do that for some of my libraries, but that is not the issue we discuss here. The same difference (SO 3x bigger than DLL) I see for any library, whether LCL is included or not.

A simple shared library is a few KB on Linux. Add classes for some Pzazz and it is still under 1 MB. (867 KB on ARM-LINUX.Note it still pulls in ALL of classes)

Unfortunately I do not have simple libraries. Compare library size for a library that takes min. 200kB on Windows. What takes it on your Linux then?

The template for a shared library looks plainly stupid for Linux, but also in general.

The default library template in Lazarus of course comes without any LCL dependency.

[Thaddy]

Unfortunately I do not have simple libraries. Compare library size for a library that takes min. 200kB on Windows. What takes it on your Linux then?

Depends: between 253 K and 800K.

[tk]

Depends: between 253 K and 800K.

Same lpi, same bitness, same compiler options, 253K a SO on Linux and 200K a DLL on Windows?
If yes then I don't believe you. Make a proof.

[Thaddy]

Make a proof.

I interpreted it differently - I tested one simple and one complex shared lib - but this should be around 250k on arm-linux. On Windows and 32bit intel  linux it is much smaller:

Code: [Select]

library simple;
{$CALLING C}
uses initc; // this is actually needed for an so to make it callable from other languages.

function AddMe(const a,b:integer):integer;
begin
  AddMe := a+b;
end;

exports AddMe;
begin
end.
Ps. the .o for this is just 2667 bytes on arm.

[tk]

I interpreted it differently

Let's stay on i386 for simplicity. Tried your small lib now on Win,Linux,OS X. Results attached. Still Linux binary has the biggest size (dll is even 5 times smaller than so).
.o files are completely different matter I think, their sizes are similar.

However, these small libs are not representative enough for the problem described in my first post.
Because IMO here the binary file overhead and/or RTL differences clearly win against the size of compiled user code.

[Fred vS]

Hello.

The size of fpc libraries are too big because dynamic runtime packages are not supported yet.

But it is WIP.

http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library-td5718200.html

Fre;D

[Thaddy]

Yes. But that is a one time penalty,about 200K-250K, and the size should not grow significantly in size compared to a dll except for that 200K-250K penalty that is the runtime lib.
That means the sizes should converge to a similar size with larger dynlibs. And that is what I see.

[tk]

That means the sizes should converge to a similar size with larger dynlibs. And that is what I see.

Unfortunatelly that is what I don't see.

EDIT: Finally I solved this by adding -k--gc-sections to compiler options. Now the linux builds have similar size as OSX dylibs, which is ca 1.4x the size of Windows DLLs. And the Linux build map file finally shows the removed sections. I don't know why, because I have -XX option checked, but it works.

[Jonas Maebe]

If you compile with the -Cn command line parameter, you should be able to see which parameters FPC is passing to ld by looking at the generated ppas.sh file.

[SymbolicFrank]

I want my executable to include anything it might even remotely need. Because I want it to run on all the different versions.

It's called "dll hell", although they could be called .so or whatever instead.

If you want tiny, you also want endless dependencies.