[fpc-pascal] Internal linker status

[Florian Klaempfl]

Sasa Zeman wrote:
>>>> If you want to work with development code i think it is better to find
>>>> out
>>>> it yourself what is going wrong. For me it works on all development
>>>> systems  that i use.
>> The issue 4922 has nothing todo with the internal linker which is still
>> under development and not ready for public use.
> 
> In previous quoted sentence you refer  not to use development code. The
> problem with issue 4922 force using development code and that is all -
> cascade bugs are expected using unstable releases. I suppose you are not
> willing to point to code for solution 4922 in order to correct sources in
> 2.0.2 and use it.

No. 2.0.2 is a release and it sources won't change. If the fix proves
it's stability in 2.1.1, it will be merged back to 2.0.3 which will be
the base for the next release: 2.0.4.

> 
> As GNU linker is very problematic on Win32, 

We used the GNU linker on win32 for years and it worked. We know that it
has it's flaws but it isn't that bad after all.

> it was reasonable step to test
> internal linker when development code is using.

There are different levels of development code. the linker is really
bleeding edge, most other stuff in 2.1.1 is rather stable.

> 
>>> 143,872 Demo-GNU.exe // With GNU linker
>>> 551,464 Demo-INT.exe // With internal linker
> 
>> Exactly another reason why it is not public. You are comparing different
>> things here. Using the GNU linker with smartlinking and using the internal
>> linker without smartlinking.
> 
> I comparing code produced with the same compiler parameters, except -Xi .

The internal linker doesn't support all options yet.

> Perhaps -Xi in that release disabled or enabled some other parameter(s). Or
> command "make clean all" did not clean all previous produced code. That is
> not possible to be determinated at the moment
> 
> The fact is that after manual cleaning directory and using the latest SVN
> release internal llinked worked, produced Lazarus executable using internal
> linker (without using -Xi and deleted LD.exe) was 39MB. Stripping gaves 33MB
> and  executing fails. It seems that strip utility removed critical executing
> code from header.
> 
> Duration compiling complete Lazarus code is about 6 times worst than with
> LD. Regarding reported problem using not only phisical memory, creating map
> file spend most of the time. Since this is development release, after
> correcting problem with using memory, disabling creating map file and
> checking problem with mentioned problem with (possibly incorrect) executable
> heeader, linker will probably be near to Delphi's.
> 
> Good lack.
> 
> 
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>