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
> 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
_
> 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
> 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 noti
> 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. A
> >> 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 pub
Dimitris,
> when a real number overflows the program halts with EInvalidOp error.
> How can I make the program behave the more standard way, where the
> variable gets the value "inf" and execution continues normally? This is
> vital for many tasks, like fractal computation.
You can use try..excep
> 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 wo
> Thank you very much, this solves the problem though I think that
> performance-wise it is not optimal. What is the reason for freepascal
> being not IEEE-spec compliant? Is it backwards compatibility?
FPC is IEEE-spec compliant, since all computer follow up floating point
standard. It should fol
FPC 2.0.2 do not rasie exception on integer/floats division by Zero, which
is suitable for calucaltion I currently developing. Instead, division return
infinity:
writeln(1/0) -> +inf
writeln(1.0/0) -> +inf
With excluding zero exception from SetExceptionMask(), it dows not turn on
the exception (u
This bug report cannot be submit.
Log of SVN release #3198 building by 2.0.2:
C:/pp/bin/i386-Win32/gmkdir.exe -p units/i386-win32
c:/lazarus/source/fpc/2.1/compiler/ppc386.exe -XX -CX -Ur -Xs -O2 -n -Fuc:/l
azar
us/source/fpc/2.1/rtl/units/i386-win32 -FE. -FUunits/i386-win32 -di386 -dREL
EASE
bui
> > FPC 2.0.2 do not rasie exception on integer/floats division by Zero,
which
> > is suitable for calucaltion I currently developing. Instead, division
> > return infinity:
> >
> > writeln(1/0) -> +inf
> > writeln(1.0/0) -> +inf
> Already fixed.
Unfortunatelly, bug still persists when division is
> We don't consider this as a bug, it's for delphi compatibility reasons.
> These expressions are evaluated at compile time, so it's something
> differnt. If you want to get an error, compile with -Cr.
The -Cr will point on error in the code, however, enabling range checking
will also affect on gl
> The program won't compile with -Cr.
Program with -Cr will compile and link if all is correct. Eventually range
check error compiler can predict, will stop compilation as usually.
Otherwise, program itself will check range on each attemp to work with
arrays or calculations, which is clearly waste
> Hello , I need to know whether someone has fast routines to calculate
> crc32 of let's say 64 k buffer.
> Any help would be appreciated
Almost all table oriented impelmentations using pointer arithmetic are fast
enough. You may be interested to take a look CRC32 unit on my site. It is
opera
> People will complain, if FPC isn't delphi compatible.
FP actually is not 100% Delphi compatible by default mode and it is not
intention to be (regarding available informations on internet) it is
actually intented to be compatible with Turbo/Borland Pascal, I suppose.
Delphi simulation mode (-Sd,
> Well, I consider the problem as minor so I don't know if it's worth to
> introduce a new switch. I guess the best solution is to throw always a
> hint. Since 1/0=Inf is IEEE compliant, it's no real error. If people
> really want an error, they can create their own error msg file making
> the hint
Regarding division problem. Florian was precise in explanation (suggested to
be part of documentation).
> I think even _if_ there is a focus on getting the memusage down (and there
> is, it is one of the internal linkers objectives), it should be more to
let
> Lazarus perform optimally with say 51
> IMHO you should already be happy with the internal linker because you are
> now able to create a smartlinked lazarus without requiring 1+ GB of
> memory.
FPC and Lazarus are just testing alternatives. Comparing FPC performance of
internal linker with Delphi's or with external LD, I found no reas
> Not in a modern version. It won't even start probably.
FPC can be comparable with command line compiler of Delphi 7. D2005-6
compile C/C++ (CBuilder) code among other features raise complexity, which
are not FPC tasks.
> If we would try to match that, uncompromisingly, with Free Pascal, we
> wo
> Please keep in mind that FPC/Lazarus is OSS and that it lives from it's
> user's contributions.
It seem that you missunderstood. As a developer, I'm not interested in
looking FPC code nor tracking future plans (details are alse never
published, only future plans), but using it to create working
> > FPC can be comparable with command line compiler of Delphi 7.
> Yes? So Delphi has multi platform support and has maintainable compiler
> sources?
Multi platform support was not an issue here.
> > It seems that all previously produced compiled code left in memory, even
> if It seems but it is
> In that case, you cannot make any sort of demands or set our
> priorities. You can voice your opinion of course (which you did), but
Please do not mis-interprete. I'm aware that any meber of FPC can be a bit
more sensitive, but that is not a reson for inpropriate behavior instead of
cultural arg
From: "Jonas Maebe" <[EMAIL PROTECTED]>
> > Since I testing FPC and Lazarus, I'm intersting in using it.
> > However, FPC and Lazarus currently cannot be competition
> > to Delphi/Kylix. But the most important advantages are daily
> > updates and upgrades and we hope it
> > will become worthy c
> The problem was when you kept insisting that the compiler wastes
> memory and should be optimized (with a target of 128MB physical
Please read all carfully, you mis-interpreting whole thing again.
If you want more developers in the team, simply "yes or not" is not enough.
Explain how else to kn
> Please do not come all the way here just to tell us that Lazarus is
> not suitable as a RAD tool. This is typical Troll behavior.
You people are really odd... Please do not mis-interprete.
I spend most of my spare time and money to test FPC and Lazarus, post more
than several bug reports and su
> Disadvantages of Delphi:
> 2. It's closed source, if it's buggy you're lost.
Main problems comes from RTL and VCL, not a compiler - it is
stable, at least for D7. As D7 Pro+ comes with RTL and VCL sources, it is
easy to fix and recompile both. And there is many excelent free and
OpenSource third
> If you really want to make Free Pascal / Lazarus better you should go
> with specific topics, and discuss what would be a solution to improve
> each small parts where you consider Delphi to be better then Lazarus.
That is exactly almost literally counted in the first message of the thread.
Takin
28 matches
Mail list logo
