Hello.

Here size of "nude" program and library compiled with fpc 2.7.1. Why is it a so big size-difference ?

Compiled with => fpc 2.7.1 => linux 64
Compiler parameters : -MObjFPC -Scghi -CX -Os1 -Xs -XX -vewnhi -fPIC

program prognude ;
begin
end.
=> 26.9 k
library libnude ;
begin
end.
=> 196.3 k
______________________________

Here with same 'uos' unit in 'uses' :

program proguos ;
uses
uos;
begin
end.
=> 211.1 k
library libuos ;
uses
uos;
begin
end.
=> 1000.1 k

Many thanks.

I suspect PIC is to blame. This adds a lot of tables to your library.

Michael.

Hum, when compile with or without -fPIC, it does not change anything,... i get exactly the same size...

If I am correct, the compiler will add the PIC by itself. But someone of the compiler team should confirm this...

Michael.

If I am correct, the compiler will add the PIC by itself. But someone of the compiler team should confirm this... Michael.

Yep, Michael, many thanks for answer.

Sorry to insist on that, but the size of fp library is very too big vs other libraries (C for example).

But there are huge advantages to use fp library : for example i never was able to create dynamic loaded libraries who load dynamically other libraries ( not possible with gcc, nor with M$ Visual Studio).

But with fp, it is possible...

So, if it could be possible to create fp library with a reasonable size, i think fp library is the future for all other libraries...

Many thanks.

Fred van Stappen wrote

Sorry to insist on that, but the size of fp library is very too big vs other libraries (C for example).

The size of FPC libraries will always(*) be bigger then e.g. C ones, because in FPC the RTL is statically linked into the program/library, while C libraries link against the C runtime library.

(*) Once dynamic runtime packages are supported this might change though...

Regards,
Sven

>(*) Once dynamic runtime packages are supported this might change

though...

>Regards, > Sven

Ok, thanks Sven, that will be the best...

But before the triumph of fp, i will do that universal audio open source library with fp too...

Many thanks for all of you, fp designers....

Fred

> Sorry to insist on that, but the size of fp library is very too big vs

other libraries (C for example).

Hello.

This is a old topic but maybe there are some news...

Are dynamic runtime packages supported yet ?

Thanks.

Fre;D

-----
Many thanks ;-)

> Sorry to insist on that, but the size of fp library is very too big vs

other libraries (C for example).

Hello.

This is a old topic but maybe there are some news...

Are dynamic runtime packages supported yet ?

Thanks.

Fre;D

-----
Many thanks ;-)

No, they're still WIP.

Regards,
Sven

>> Sorry to insist on that, but the size of fp library is very too big >> vs other libraries (C for example).

Except in the case of KOL applications where many of my KOL Dll's/Exe's were smaller than any C/C++ tool could ever create... But KOL is window's specific mostly. Someone ported it, AFAIR, to linux using.... some gui widget set, but I don't remember how far that got

Hello.

Sorry to come back with this story but there are (good) news.

Using *--gc-sections* makes the library smartlinked.

So the question is:

Why FPC does not provide *--gc-sections* to the linker with the -XX paramer for libraries ? (Bug ?)

Fre;D

-----
Many thanks ;-)

fredvs wrote

*

--gc-sections

*

*

--gc-sections

*

to the linker with the -XX paramer for libraries ? (Bug ?) Fre;D

Nobody uses fpc library here ?

Strange that a (big) problem with maybe a solution does not interest anybody.

The size of fpc libraries makes fpc-libraries not usable in a real world.

I use some audio C libraries and a fpc library (that only link headers of that C libraries) is 10 times bigger than the C libraries !

And when a solution (or bug) is found ---> only silence as answer.

Fre;D

-----
Many thanks ;-)

There is no problem.

The size of fpc libraries makes fpc-libraries not usable in a real world.

Why ?

There is no bug. You are comparing apples with pears.

A C library in the traditional unix sense is a set of routines that requires other libraries to run - ultimately requiring libc.

A FPC library - due to it's windows origings heritage - is more like a static program. It's almost 100% standalone, and does not require other libraries to function (except the ones you explicitly link in). Inevitably, it is bigger.

Once dynamic packages are implemented, we can start comparing apples with apples, and pears with pears. a dynamic package is more like a C library in the unix sense. It makes sense to compare those.

If you want to compare today, you need to add the sizes of all the C libraries that are loaded during execution of a C program with the size of an FPC program.

I think you'll find that the sizes of FPC programs are not so different then.

Just check the size of libc:

ls /lib/x86_64-linux-gnu/libc-2.19.so -l

-rwxr-xr-x 1 root root 1853216 Mar 21 20:24 /lib/x86_64-linux-gnu/libc-2.19.so*

That is almost 2Mb that is linked in to every C library and program.

Michael.

Michael Van Canneyt wrote

Ha, news, finally.

Huh, did you read my post ?

It talk about smartlinking of libraries that does not work.

After lot of fight, there is a solution: using -*-gc-sections*.

And the question was :

/Why FPC does not provide --gc-sections to the linker with the -XX paramer for libraries ? (Bug ?) /

Fre;D

-----
Many thanks ;-)

I did.

I responded to the statement that fpc libraries are big and "unusable".

Not providing an option is not a bug.
At best, providing this option is a feature request on your part.

Why it does not provide the option?
For the same reason that it doesn't strip binaries by default, I suppose. Or maybe this option didn't exist when the FPC library support was implemented ? Maybe there are even other reasons I am not aware of.

But even when you do the --gc-sections, your library will still be bigger than corresponding C libraries for the reasons I outlined in my initial response.

Michael.

But if FPC also uses libc, in units like unix/linux/other .pp units, that means FPC is using C libs too..

This also was a claim made by Golang that it doesn't use C code so you are comparing apples to Women, but in fact, the women eat apples and oranges and See (C) too.

Hopefully that's all there is to it, but how do you know that this doesn't just work for your current code and is not reliable for all situations?

If that's all there is too it, that's cool! But maybe fpc left it out for a reason: like it only works in some test cases of libraries, but not all test cases?

Unless the user specifically includes it: It does not.

Michael.

noreply wrote

It works for all situations, so I propose that fpc add --gc-sections as parameter for the linker if the user has used -XX parameter to compile a library.

Fre;D

-----
Many thanks ;-)

2017-05-16 10:15 GMT+02:00 fredvs :

It works for all situations, so I propose that fpc add --gc-sections as parameter for the linker if the user has used -XX parameter to compile a library.

for features requests please use https://bugs.freepascal.org .

Maciej Izak wrote

Thanks but before to ask for that (essential) feature: ---> advices, ideas, warnings are welcome.

Also, as you can see, it is important to be sure that the request is perfectly understood (and, sorry, but I have lot of doubt about this).

Fre;D

Fre;D

-----
Many thanks ;-)

And why is that ?

What can be misunderstood about adding --gc-sections to the linker options if -XX is used on the command-line ?

Michael.

fredvs wrote

It works for all situations, so I propose that fpc add --gc-sections as parameter for the linker if the user has used -XX parameter to compile a library.

Does it work for all situations? I remember a bug for the rust compiler that broke libraries when --gc-sections was used, because it removed the metadata that rust needed to load the library. One of the fpc devs can probably say whether fpc may have a similar problem.

I know with gcc you will need -ffunction-sections and -fdata-sections if you want --gc-sections to do anything, and there are warnings attached to those (see the gcc man page).

Henry

You risk losing e.g. resources.
This is typically what needs to be investigated.

Michael.

In our previous episode, fredvs said:

Nobody uses fpc library here ?

Yes, but I don't care about size unless it is outrageous.

Michael Van Canneyt wrote

What can be misunderstood about adding --gc-sections to the linker options if -XX is used on the command-line ?

Ha, the way you present it seems to show that you did understand it ;-)

OK, maybe is it time to add a feature request...

Fre;D

-----
Many thanks ;-)

In our previous episode, Michael Van Canneyt said:

That also goes for the main application. Such sections should be marked with KEEP() in the linker script.

Before filing a request, you can already check yourself what happens with form data if you compile a lazarus form into the library.

Michael.

Michael Van Canneyt wrote

Huh, with all the respect that I have for LCL, I was never able to compile a Lazarus form into library (even without --gc-sections or -XX) . On the other side, with forms from fpGUI or MSEgui, no form data loosed while compiling forms into library with --gc-sections.

PS: Re-huh, the libraries that I compile do not store form-data (even no data at all).

Fre;D

-----
Many thanks ;-)

Marco van de Voort wrote

Yes and it is valable too for programs compiled with -XX.

Fre;D

-----
Many thanks ;-)

As far as I know, they don't use FPC resources for this ?

PS: Re-huh, the libraries that I compile do not store form-data (even no data at all).

Possibly, but this is something that must be checked before implementing such an option...

Michael.

Okay hold on. All situations.
Either you are a serious Edsgar Dijkstra fan, and you have proven it to be correct (unlikely) or you have all the test cases of the entire universe and are a unit testing nutcase..
All the chess board peices and positions on the game board have all been tested in all situations...
No..

But, seriously... if it works in many many many situations I guess that is "good enough"
:-)

Hrm... I think way back I was able to compile a lcl form into a library, as a plugin for lazarusrb, but, had issues with showmessage requiring two mouse clicks instead of one click to close it, or some strange behaviors..

But it was such a long time ago that I forgot. Some strange message loop issues AFAIR

Hello.

OK, I see that fpc team is afraid to change something that mom-Delphi did not do.

So, to resume, for people who wants to smartlink their libraries, you may use this command:

*fpc -k--gc-sections my_smartlinked_library.pas*

Fre;D

-----
Many thanks ;-)

2017-05-17 13:32 GMT+02:00 fredvs :

OK, I see that fpc team is afraid to change something that mom-Delphi did not do.

You don't know that. Lack of bug report / feature request on mantis, means that the feature request doesn't exist in any formal way. Sometimes is good to have reported thing like this on bugtracker for documentation purposes (even if finally will be rejected).

fredvs wrote

Hello. OK, I see that fpc team is afraid to change something that mom-Delphi did not do.

This is simply not correct and a *very* unfair statement on your part. Mails like this will really not get you anywhere.

1. You didn't even file an official request in the bugtracker ?

2. Where did we say we would not do this ? We're just careful, since the effect is not known.

3. You didn't even test the resources thing. It means we will need to test this. This takes time, and the issue is not considered very important, so this time is indeed not spent right away.

4. Delphi doesn't use GNU ld, so this comparison is totally without basis.

With this mail, you're simply behaving like a small girl that didn't get her ice cream right away...

Michael.

Michael Van Canneyt wrote

Yes, I now. I know also that if you do not speak hot, people does not listen.
By the way, I sent advices about size of fpc libraries more than 10 years ago.
A lot of "work in progress" as answers but nothing change.

A other thing that I discover: it is extremely sensible to talk about linkers.
In FreeBSD forum, I was insulted because I reveal that their linker (GNU ld) was not compatible with FreeBSD multi-arch design.

But, IMHO, if fpc uses a external linker, it is also part of the compilation process.
And each feature of the linker should be analyzed.

Michael Van Canneyt wrote

You didn't even file an official request in the bugtracker ?

Because I tried already and because I know the (rejected) answer.

Michael Van Canneyt wrote

Of course I tested it, why do you write this ?

Michael Van Canneyt wrote

With this mail, you're simply behaving like a small girl that didn't get her ice cream right away...

Ha, so you do not know me.
If I do not get my ice cream, I am much more unbearable.

Fre;D

-----
Many thanks ;-)

fredvs wrote

But, IMHO, if fpc uses a external linker, it is also part of the compilation process. And each feature of the linker should be analyzed.

We are agreed on that.

Michael Van Canneyt wrote > You didn't even file an official request in the bugtracker ? Because I tried already and because I know the (rejected) answer.

Where is this bugreport ?

Michael.

Michael Van Canneyt wrote

I was talking about earlier other requests.

But now, if you think that the request has a little chance to be considered, I will sent a bugreport with great pleasure,

Fre;D

-----
Many thanks ;-)

Each case is always judged separately.

But now, if you think that the request has a little chance to be considered, I will sent a bugreport with great pleasure,

To the best of my knowledge, we only refuse requests if there is (for us) a good reason.

Until now, I see no reason why we would refuse your request ? I do still think that we need to investigate it somewhat more thoroughly.

So if you submit a request, you actually improve the probability it gets looked at and subsequently added...

If you could add a sample library project with some resources (they need not necessarily be forms), then this would help us investigate the case.

Michael.