If you read the article, it's clearly said that the FPC v.2.6.4 arm-linux
package was taken from FPC's official SourceForge repository, not from the
apt-get (raspbian) repository. I refered to the article is more about how I
installed FPC on an Raspberry Pi device, not about what I installed. So,
On 02/27/2015 07:39 PM, Sven Barth wrote:
Considering that they are activated by the local switch {$interfaces
corba} (and the reference counted ones by {$interfaces com}) you
hardly can't blame anyone for using these terms...
I did not want to blame mse to use the term, but fpc for forcing
On 02 Mar 2015, at 09:14, Victor Matuzenko wrote:
I have a (very) huge project, and compilation of a shared library
inside it fails at the linking stage:
/usr/bin/ld: /long/directory/file.o: relocation R_X86_64_32S
against `FPC_ABSMASK_SINGLE' can not be used when making a shared
Looking at 2.7.1 for i386, InterLockedIncrement() appears to be take a
signed 32-bit as its parameter but to increment as an unsigned and wrap
to zero.
Is this a reliable interpretation in the general case, or if I use it to
e.g. count how many times a thread spins are there other cases that
Could be.
-Original Message-
From: fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Mattias
Gaertner
Sent: Sunday, March 1, 2015 7:52 AM
To: fpc-pascal@lists.freepascal.org
Subject: [fpc-pascal] the unexplained 666
Hi,
Today I
How can I fix it? Should I pass -fPIC argument (and how to do this)?
AFAIK, PIC code generation is turn on by default.
Are you sure you don't have an opposite problem?
Sometimes when you have asm code written with hard-coded offsets you can get a
module which can't be PIC-compiled.
See fpc -h
On Sun, Mar 01, 2015 at 04:29:31PM +0100, Mattias Gaertner wrote:
In our previous episode, Mattias Gaertner said:
Why not write 666? Maybe some religious reasons? ;)
No, simply that octal literal support is newer than the *nix rtl.
ok, although then again: When came binary and
Hi!
I have a (very) huge project, and compilation of a shared library inside
it fails at the linking stage:
/usr/bin/ld: /long/directory/file.o: relocation R_X86_64_32S against
`FPC_ABSMASK_SINGLE' can not be used when making a shared object;
recompile with -fPIC
/long/directory/file.o:
On 02/28/2015 08:20 PM, Mark Morgan Lloyd wrote:
Looking at
http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#Initialization_and_Finalization
there are dire warnings that TThread.Create() shouldn't be overridden.
???
The Docs say Normally you are required to override
Michael Schnell wrote:
On 02/28/2015 08:20 PM, Mark Morgan Lloyd wrote:
Looking at
http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#Initialization_and_Finalization
there are dire warnings that TThread.Create() shouldn't be overridden.
???
The Docs say Normally you
On Mon, 02 Mar 2015 09:05:42 +
Mark Morgan Lloyd markmll.fpc-pas...@telemetry.co.uk wrote:
Mattias Gaertner wrote:
On Sat, 28 Feb 2015 19:20:49 +
Mark Morgan Lloyd markmll.fpc-pas...@telemetry.co.uk wrote:
[...]
Looking at
Mattias Gaertner wrote:
On Sat, 28 Feb 2015 19:20:49 +
Mark Morgan Lloyd markmll.fpc-pas...@telemetry.co.uk wrote:
[...]
Looking at
http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#Initialization_and_Finalization
there are dire warnings that TThread.Create()
12 matches
Mail list logo
