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 funct
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 - fpc-pascal@lists.freepascal.
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 succes
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 lclexten
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 po
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 vir
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 supp
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
On 31 May 2010, at 16:26, Matthias Klumpp wrote:
> On Mon, 31 May 2010 14:31:19 +0200, Jonas Maebe
> 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 register,
>> and th
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 Mon, 31 May 2010 14:31:19 +0200, Jonas Maebe
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 happen?
>
> It'
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 act
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
default
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 contai
> 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 cor
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
16 matches
Mail list logo
