Re: [fpc-pascal] Internal linker status
> 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Internal linker status
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@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Internal linker status
> >> 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Internal linker status
>> 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Internal linker status
> 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Internal linker status
>> 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Internal linker status
> 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Internal linker status
>> 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Internal linker status
> commandline flag -Xi Thank you. This information is not available with compiler options help list. Sasa -- www.szutils.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Internal linker status
>> 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Internal linker status
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Internal linker status
> > 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Internal linker status
>> 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Internal linker status
> 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Internal linker status
> What is the current states of internal linker developing? Basic linking for win32 works ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Internal linker status
What is the current states of internal linker developing? Sasa -- www.szutils.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Internal linker?
On Fri, 3 Mar 2006, chromdildo wrote: > Hi, > > What about the "new internal linker" ? > Is it already available in the development tree? It is available in the 'linker' branch in SVN. > What has changed? Any documents to read? No documents that I know of. The current status is that the compiler can now work without any external tools: both assembler and linker are internal in the compiler for at least windows. 'make cycle' runs, cross-compilation and linking works, the compiler produces a lazarus binary which is functional AFAIK. I have not seen any timings yet, but I have seen reports that memory usage has been greatly reduced. Peter Vreman has done most, if not all, development on this. He can say more about it than I can. Michael. > > Thanks and best regards. > chrom > > > What is new is that the compiler does all the work for you. > > > > What is still missing, is Win32 support. A DLL is a different beast > > than a shared lib on linux, because it's usually self-contained, > > and because it can't export variables. Mainly, this is package stuff. > > > > The new internal linker should make this possible... > > > > Michael. > > ___ > > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > > > > > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Internal linker?
Hi, What about the "new internal linker" ? Is it already available in the development tree? What has changed? Any documents to read? Thanks and best regards. chrom > What is new is that the compiler does all the work for you. > > What is still missing, is Win32 support. A DLL is a different beast > than a shared lib on linux, because it's usually self-contained, > and because it can't export variables. Mainly, this is package stuff. > > The new internal linker should make this possible... > > Michael. > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal