Internal linker status

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Internal linker status

Sasa Zeman
What is the current states of  internal linker developing?

Sasa
--
www.szutils.net


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Internal linker status

Peter Vreman
> What is the current states of  internal linker developing?

Basic linking for win32 works



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Internal linker status

Sasa Zeman
> Basic linking for win32 works

Thank you for information.

Allowing compiler declatarion of INTERNALLINKER in fpcdefs.inc and
recompiling the latest SVN revision (linker branches) is not enough to use
it.

Please provide exact steps in order to use internal linker.

Sasa
--
www.szutils.net

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Internal linker status

Marco van de Voort
> > Basic linking for win32 works
>
> Thank you for information.
>
> Allowing compiler declatarion of INTERNALLINKER in fpcdefs.inc and
> recompiling the latest SVN revision (linker branches) is not enough to use
> it.
>
> Please provide exact steps in order to use internal linker.

commandline flag -Xi
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Internal linker status

Vincent Snijders
In reply to this post by Sasa Zeman
Sasa Zeman schreef:

>> Basic linking for win32 works
>
> Thank you for information.
>
> Allowing compiler declatarion of INTERNALLINKER in fpcdefs.inc and
> recompiling the latest SVN revision (linker branches) is not enough to use
> it.
>
> Please provide exact steps in order to use internal linker.
>

All you need to do to test the internal linker is pass the -Xi to compiler.

So:
ppc386 -Xi hello.pas

Vincent
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Internal linker status

Peter Vreman
In reply to this post by Sasa Zeman
>> Basic linking for win32 works
>
> Thank you for information.
>
> Allowing compiler declatarion of INTERNALLINKER in fpcdefs.inc and
> recompiling the latest SVN revision (linker branches) is not enough to use
> it.
>
> Please provide exact steps in order to use internal linker.

Please provide exact steps what you did to detect that it is not used.





_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Internal linker status

Peter Vreman
In reply to this post by Vincent Snijders
>> Allowing compiler declatarion of INTERNALLINKER in fpcdefs.inc and
>> recompiling the latest SVN revision (linker branches) is not enough to
>> use
>> it.
>>
>> Please provide exact steps in order to use internal linker.
>>
>
> All you need to do to test the internal linker is pass the -Xi to
> compiler.
>
> So:
> ppc386 -Xi hello.pas

The -Xi is only needed for SVN trunk. For the linker branch it is enabled
by default.



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Internal linker status

Sasa Zeman
In reply to this post by Marco van de Voort
> commandline flag -Xi

Thank you.

This information is not available with compiler options help list.

Sasa
--
www.szutils.net

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Internal linker status

Peter Vreman
>> commandline flag -Xi
>
> Thank you.
>
> This information is not available with compiler options help list.

Ofcourse not, becuase it is a development/test option. Don't forget you
are using development code. Especially the linker branch has no garauntees
at all that it compiles/works.



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Internal linker status

Sasa Zeman
> Please provide exact steps what you did to detect that it is not used.

1. Download the latest SVN revision from
http://svn.freepascal.org/svn/fpc/branches/linker/
(revision 3065 if I remeber correctly) and trunk FPC update as well

2. After I compared current trunk and branch version I have noticed that
they are practically the same, except the
enabled directive and last added hash class in cclasses.pas (which was not
used), I have enabled directive INTERNALLINKER ({ $define INTERNALLINKER} )
to trung subversion.

3. Rrename  LD.EXE to LD.BAK
4. Clean and build all trunk SVN reslease by ...FPC/make clean all
5. Install: ...FPC/make install
6. Compile example I sent from mantis issue 4922:

>fpc -Sd demo.lpr
Free Pascal Compiler version 2.1.1 [2006/03/28] for i386
Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: Win32 for i386
Compiling demo.lpr
Linking demo.exe
Error: Util ld.exe not found, switching to external linking
Error: C:\pp\bin\i386-Win32\ppc386.exe returned an error exitcode (normal if
you did not specify a source file to be compiled)

> The -Xi is only needed for SVN trunk. For the linker branch it is enabled
> by default.

I assumed that allowing directive will automatically use linternal linker.
However, in this case, without explicitly adding -Xi whas unable to link.
Please specify what else should be changed to achieve that behavior.

Executable (of example from upper wrote steps) linkined by internal linker
is 5 times larger than linked with GNU linker (suppose debugger symbols
again, which BTW can not be stripped by strip utility). Please explain cause
of it and tasks ware on your list to produce final version of internal
linker.

Is there a possibilitie to currently produce smaller executable with
internal linker?

> > This information is not available with compiler options help list.
> Ofcourse not, becuase it is a development/test option. Don't forget you
> are using development code. Especially the linker branch has no garauntees
> at all that it compiles/works.

I'm fully aware of that and that is exact reason of upper wrote steps.

Sasa
--
www.szutils.net

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Internal linker status

Peter Vreman
>> Please provide exact steps what you did to detect that it is not used.
>
> 1. Download the latest SVN revision from
> http://svn.freepascal.org/svn/fpc/branches/linker/
> (revision 3065 if I remeber correctly) and trunk FPC update as well
>
> 2. After I compared current trunk and branch version I have noticed that
> they are practically the same, except the
> enabled directive and last added hash class in cclasses.pas (which was not
> used), I have enabled directive INTERNALLINKER ({ $define INTERNALLINKER}
> )
> to trung subversion.
>
> 3. Rrename  LD.EXE to LD.BAK
> 4. Clean and build all trunk SVN reslease by ...FPC/make clean all
> 5. Install: ...FPC/make install
> 6. Compile example I sent from mantis issue 4922:
>
>>fpc -Sd demo.lpr
> Free Pascal Compiler version 2.1.1 [2006/03/28] for i386
> Copyright (c) 1993-2005 by Florian Klaempfl
> Target OS: Win32 for i386
> Compiling demo.lpr
> Linking demo.exe
> Error: Util ld.exe not found, switching to external linking
> Error: C:\pp\bin\i386-Win32\ppc386.exe returned an error exitcode (normal
> if
> you did not specify a source file to be compiled)
>
>> The -Xi is only needed for SVN trunk. For the linker branch it is
>> enabled
>> by default.
>
> I assumed that allowing directive will automatically use linternal linker.
> However, in this case, without explicitly adding -Xi whas unable to link.
> Please specify what else should be changed to achieve that behavior.

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.


> Executable (of example from upper wrote steps) linkined by internal linker
> is 5 times larger than linked with GNU linker (suppose debugger symbols
> again, which BTW can not be stripped by strip utility). Please explain
> cause

The problem with strip is already fixed and merged even to 2.0.3. I think
you should do better research yourself first before immediatly asking for
explaination.

This is asking for explaination is exactly the reason why the -Xi switch
is not documented or publicly announced.


> of it and tasks ware on your list to produce final version of internal
> linker.

There is no todo list and i can never give timelines because my time is
too limited.


> Is there a possibilitie to currently produce smaller executable with
> internal linker?

It already does, especially with debuginfo included, see below. The
lazarus.exe is with the internallinker, the lazarus1.exe using ld.

-rwxrwxrwx 1 PVreman mkgroup-l-d 38997687 Mar 29 10:11 lazarus.exe
-rwxr-xr-x 1 PVreman mkgroup-l-d 64411405 Mar 29 09:56 lazarus1.exe



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Internal linker status

Sasa Zeman
> 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.

If would I have a time to look at souce code, I would gladly become
developer member. However, my spare time is quite limited. And reason I use
development source are practicaly nature:

1. I very often using procedural types with overloading - reported by issue
4922 and solved by one of recent trunk revision

2. Have no time to read 1000's lines of code.

BTW, regarding mantis issue 4922. Originally reported problem is in 4920
with precise informations of the problem and referal code. Remember you
marked the problem non-existed.

My goal is to use working product, otherwise I would not send the issue.

> The problem with strip is already fixed and merged even to 2.0.3. I think
> you should do better research yourself first before immediatly asking for
> explaination.

With current SVN release the problem will remain unsolved without
documentation. And plese refer to upper wroten - I do not have time to read
source code and there is no other way solving problem without wroten
documentation, but asking concrete question.

> This is asking for explaination is exactly the reason why the -Xi switch
> is not documented or publicly announced.

I assume not many people know of it's existion. This is mailng list and one
of it's purpose is solving problems giving suggestions, etc. I haven't
notice phpBB forum for specific questions. I appology if exists.

> of it and tasks ware on your list to produce final version of internal
> linker.

There is no todo list and i can never give timelines because my time is too
limited.

> Is there a possibilitie to currently produce smaller executable with
> internal linker?
> It already does, especially with debuginfo included, see below. The
> lazarus.exe is with the internallinker, the lazarus1.exe using ld.
> -rwxrwxrwx 1 PVreman mkgroup-l-d 38997687 Mar 29 10:11 lazarus.exe
> -rwxr-xr-x 1 PVreman mkgroup-l-d 64411405 Mar 29 09:56 lazarus1.exe

Without documentation (several time noticed there is no documentation or
"What is new file"), real executable without debug infoc can not be produced
correctly. I refer to a quite small code to be compiled using internal
linker and LD ( code provided with issue 4922):

143,872 Demo-GNU.exe // With GNU linker
551,464 Demo-INT.exe // With internal linker

The lazarus.exe is created by todays SVN revision using:
make clean all OPT="-Xi -Xs"

Unfortunately, there are present practicaly problems (as well as with GNU
linker):

1. Building time is several times worst comparing with LD and produced exe
with 39,036,385 bytes. Stripped EXE is 33,887,549 bytes. Stripped exe linked
with LD is about 7 MB.

2. Memory using is over 80MB. This is quite problematic on computers with
128MB and less. That is reason that Window uses swapfile all the time. It
would be very useful optimizing  algorithm to use only available phisical
memory for critical data for operation and flush produced code to exe file
more often reusing phisical memory more often.

Hope this will help to improve the product.

Sasa
--
www.szutils.net

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

[OFF-TOPIC] language history

Rodrigo Palhano

kind of interesting



http://www.levenez.com/lang/history.html





 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Internal linker status

Peter Vreman
In reply to this post by Sasa Zeman
>> 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.
>
> If would I have a time to look at souce code, I would gladly become
> developer member. However, my spare time is quite limited. And reason I
> use
> development source are practicaly nature:
>
> 1. I very often using procedural types with overloading - reported by
> issue
> 4922 and solved by one of recent trunk revision
>
> 2. Have no time to read 1000's lines of code.
>
> BTW, regarding mantis issue 4922. Originally reported problem is in 4920
> with precise informations of the problem and referal code. Remember you
> marked the problem non-existed.
>
> My goal is to use working product, otherwise I would not send the issue.

The issue 4922 has nothing todo with the internal linker which is still
under development and not ready for public use.


>> The problem with strip is already fixed and merged even to 2.0.3. I
>> think
>> you should do better research yourself first before immediatly asking
>> for
>> explaination.
>
> With current SVN release the problem will remain unsolved without
> documentation. And plese refer to upper wroten - I do not have time to
> read
> source code and there is no other way solving problem without wroten
> documentation, but asking concrete question.
>
>> This is asking for explaination is exactly the reason why the -Xi switch
>> is not documented or publicly announced.
>
> I assume not many people know of it's existion. This is mailng list and
> one
> of it's purpose is solving problems giving suggestions, etc. I haven't
> notice phpBB forum for specific questions. I appology if exists.
>
>> of it and tasks ware on your list to produce final version of internal
>> linker.
>
> There is no todo list and i can never give timelines because my time is
> too
> limited.
>
>> Is there a possibilitie to currently produce smaller executable with
>> internal linker?
>> It already does, especially with debuginfo included, see below. The
>> lazarus.exe is with the internallinker, the lazarus1.exe using ld.
>> -rwxrwxrwx 1 PVreman mkgroup-l-d 38997687 Mar 29 10:11 lazarus.exe
>> -rwxr-xr-x 1 PVreman mkgroup-l-d 64411405 Mar 29 09:56 lazarus1.exe
>
> Without documentation (several time noticed there is no documentation or
> "What is new file"), real executable without debug infoc can not be
> produced
> correctly. I refer to a quite small code to be compiled using internal
> linker and LD ( code provided with issue 4922):
>
> 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.



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Internal linker status

Sasa Zeman
> >> 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.

As GNU linker is very problematic on Win32, it was reasonable step to test
internal linker when development code is using.

> > 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 .
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  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: 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  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Internal linker status

Sasa Zeman
> 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.

Yes, that would be necessary. A fix for 4922 is essencial.

> 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.

On Windows platform with small ammount of phisical memory (<=128MB),
compiling is very inconveniente and slow. New internal linker should solve
that problem as well (as mentioned already).

Sasa

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal