On 30 Mei 2010, at 19:47, Jonas Maebe wrote:
They should not be using any FPC functionality relying on floating point. Any
person who uses floating point should know that by definition it is inexact
(ranging from a little to enormously, depending on what you do).
I understand.
That last
But if I changed the milisecond part of a or b or both to anything but 0 then
the result is correct.
Correction... the bug arises NOT only if the msec part is 0. The bug arises if
msec part of both variables are EQUAL. If they are different, at least 1 msec,
then those functions produce
Hi!
If I run an application which uses a library developed with FPC on a x86
plattform, the program gets killed by SELinux because of text relocations
inside of the library.
A quick check which eu-findtextrels found a lot of those in the lib.
Exactly the same code compiled for 64bit does not
On 31 May 2010, at 14:23, Matthias Klumpp wrote:
A quick check which eu-findtextrels found a lot of those in the lib.
Exactly the same code compiled for 64bit does not contain any text
relocation.
How can this happen?
It's because we don't generate PIC (position-independent code) by
Hello,
I'm converting a few components, first developped in independant programs, into
units. I have 2 issues in the process.
-1- internal dependency
How can an interface element E0 depend on an implementation element E1? I
cannot find a way to forward-declare E1, before E0, and have its
On Mon, 31 May 2010 14:31:19 +0200, Jonas Maebe jonas.ma...@elis.ugent.be
wrote:
On 31 May 2010, at 14:23, Matthias Klumpp wrote:
A quick check which eu-findtextrels found a lot of those in the lib.
Exactly the same code compiled for 64bit does not contain any text
relocation.
How can this
In our previous episode, Matthias Klumpp said:
On x86-64, there is almost no penalty for PIC vs no PIC.
You have to recompile the entire RTL and your own code with the -Cg
compiler option to get shared libraries that only contain PIC.
Then it's up to red Hat to fix this in FPC or in
On 31 May 2010, at 16:26, Matthias Klumpp wrote:
On Mon, 31 May 2010 14:31:19 +0200, Jonas Maebe jonas.ma...@elis.ugent.be
wrote:
It's because we don't generate PIC (position-independent code) by
default on Linux-i386, because
a) PIC is fairly inefficient on i386 (it requires an extra
On 31 May 2010, at 16:16, spir ☣ wrote:
I'm converting a few components, first developped in independant programs,
into units. I have 2 issues in the process.
-1- internal dependency
How can an interface element E0 depend on an implementation element E1?
It cannot, regardless of the
Al 31/05/10 18:25, En/na Jonas Maebe ha escrit:
For instance, the first point I met is a literal notation for records r := (a:1 ;
b:2);. But fpc refuses that to me :-( (Same result with array notations.)
FPC indeed does not support this, and I'm not aware of any immediate plans to
add
According to SELinux, this is a security issue..
I guess that it may prevent some address space randomization features. I very
much doubt that it opens up security holes by itself though.
The .so should be still relocatable? The point about pic is that one
page can be mapped on different
On 31 May 2010, at 20:29, Florian Klaempfl wrote:
According to SELinux, this is a security issue..
I guess that it may prevent some address space randomization features. I
very much doubt that it opens up security holes by itself though.
The .so should be still relocatable? The point
Has anybody tried to compile the new VT port which requires
lclextensions (Luipack) on Mac OS with target widget Carbon?
I did and wasn't succesfull. Problem is, you can't compile lclextensions.
Since I am pretty new to FPC my question is, is it the right way to
generate a package (like
CA Gorski escreveu:
Has anybody tried to compile the new VT port which requires
lclextensions (Luipack) on Mac OS with target widget Carbon?
It's a know issue. See
http://forum.lazarus.freepascal.org/index.php/topic,8601.0.html
I don't have a mac, so i need patches.
I did and wasn't
or should one change the later (VT) to use FCL/LCL functions so that
it does not rely on Windows functions anymore?
Later
Why later and not immediately?
BTW: use lazarus mail list
How to?
___
fpc-pascal maillist -
CA Gorski escreveu:
or should one change the later (VT) to use FCL/LCL functions so that
it does not rely on Windows functions anymore?
Later
Why later and not immediately?
It's a lot of work.
It's easier to maintain sync with Delphi version
Lazarus/LCL has added most of the needed
16 matches
Mail list logo
