mricron is failing to build for Debian armhf, specifically we are getting a bunch of
"co-processor offset out of range" errors.
(9009) Assembling parconvert
parconvert.s: Assembler messages:
parconvert.s:3775: Error: co-processor offset out of range
parconvert.s:3783: Error: co-processor
On 17/06/15 19:06, Sven Joachim wrote:
Source: fpc
Version: 2.6.4+dfsg-6
The file fpcsrc/packages/ncurses/src/form.pp declares the objects
_nc_Default_Form and _nc_Default_Field:
,
| (* Default objects *)
| {$ifndef darwin}
| _nc_Default_Form : PFORM;cvar;external;
| _nc_Default_Field
Sergio Flores wrote:
Eg: Calling lnxp1(x) with x1 results in a SIGILL crash.
.
I've got an Android app in Play Store with around 300 thousand
downloads, and from what I've gathered, this crash happens in any
Tegra based device, and only on those.
AIUI many tegra devices
Thaddy de Koning wrote:
Not for ARMV6 EABIHF
Building for ARMV6+vfpv2 armhf is indeed a bit of a messs.
Afaict it's not possible to build a cross compiler that defaults to
armv6 ARMHF without modifying the source. With the right flags you
should be able to create a cross-compiler that is
deb http://plugwash.raspbian.org/wsf wheezy-wsf main
Thanks. So what exactly does it do? How does one access?
It's an apt repository I just set up for fixes to dependency problems
caused by the foundations webkit-related packages (they shipped an
updated webkit and a load of related updates
Pierre Free Pascal wrote:
https://archive.raspbian.org/raspbian/pool/main/f/fpc/
The 2.6.4 release is able to successfully compile
a 2.7.1 trunk compiler.
:) Thanks for confirming.
Several files are missing in this source release:
The source package which is made up of
Paul Michell wrote:
I should probablly get arround to doing a raspbian version of 2.6.4.
Yes please :)
Ok, i've just uploaded 2.6.4
https://archive.raspbian.org/raspbian/pool/main/f/fpc/
___
fpc-devel maillist -
Paul Michell wrote:
On Tuesday 21 Oct 2014 13:45:25 John Lee wrote:
Don't know why you have this problem with wheezy, but can confirm I'm
running rpi jessie, and the 'sudo' sequence above works for me ok ie does
70Mbyte download installs fpc with no errors. Haven't really tested it,
but
peter green wrote:
So it would seem FPC is currently broken on
stable Raspbian which is a pity.
It's fine on plain raspbian, unfortunately it seems that the raspberry
pi foundation are shipping a newer version of binutils which conflicts
with the fpc packaging from wheezy.
Since
John Lee wrote:
I'll do same for 2.6.x too.
Note that plain 2.6.x doesn't support armhf, in debian/raspbian we have
a patch adding support.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Paul Michell wrote:
I'm currently trying to build 2.7.1 from SVN on the latest Raspbian
(2014-09-09).
I've previously built this with either 2.6.0 from the repository, or with
Thaddy de Koning's build from March 2014.
Currently, neither of these will build 2.7.1 on a Raspberry Pi. So I have
Vsevolod Alekseyev wrote:
It's your compiler; take it in any direction you want. I'm just surprised
that Peter Green's first thought when I say ARM is Raspberry.
When I did the armhf port I was targetting it at arm linux hence I
fitted it into the exiting frameworks used for arm linux. I
Vsevolod Alekseyev wrote:
Does Free Pascal really treat ARMHF as a separate CPU target,
It didn't when I initally implemented it and from a quick look at the
code it doesn't now. What it does do is a little hacky but it followed
the pattern of what was already done and a cleaner soloution
Vsevolod Alekseyev wrote:
Please, is there a way to make Free Pascal on ARM use floating point
registers for passing floating point parameter?
Yes, build the compiler with -dFPC_ARMHF
This is supported upstream in trunk, if you want to use 2.6.x then you
can find the nessacery patches in the
Thaddy wrote:
The latter will accept the proper options, which are minimally:
CROSSOPT=-dFPC_ARMHF -CfVFPV2 -CpARMV6 -CaEABIHF
You should not need -CaEABIHF. A compiler build with -dFPC_ARMHF should
automatically use the hard float ABI (and a few other related settings).
I think all the
Reinier Olislagers wrote:
fpcup, an FPC/Lazarus build/installation/update program uses the
following steps on ARMHF Linux (e.g. raspbian, odroid):
1. Get FPC stable (2.6.2 currently) ARM bootstrap compiler binary
This compiler cannot directly build ARMHF FPC trunk.
OOI in what way does it
Michel Catudal wrote:
You will find binaries for fpc 2.6.2 with hard float support as well as larazus
1. The code is based on the code from Debian.
Out of interest what if anything did you change compared to the package
from debian? did you just rebuild it in a different environment?
Marco van de Voort wrote:
After some discussion, something to try:
try adding -dNO_THREADING to CROSSOPT (for target) and maybe also to OPT
(for host)
Unfortunately it seems that at least when building natively (note:
debian is and always has been natively built) neither OPT or CROSSOPT is
For those reading this on fpc-devel the context is that the upload of
fpc 2.6.2 to debian failed on most architectures and I would like
upstream input on sorting it out.
Abou Al Montacir wrote:
Many targets are broken: powerpc, sparc, armel, armhf. The error message
looks very similar on 3
Johan Kotze wrote:
It seems that fpc in fact does not produce ARMHF executables with the
parameters that I use. Am I using the wrong parameters or is something broken
in the ARMHF support ?
IIRC fpc doesn't set elf tags to mark objects as hardfloat, this is
something I need to look into
Michel Catudal wrote:
I am also having some issues with Lazarus, I am not sure if it is the
right forum to talk about it. I had a previous version working fine on
Rasphberry Pi.
For some reason I can't get it to work on Mele A2000G. I have compiled
it on gentoo on the Mele, using distcc and
Den Jean wrote:
On Thursday 04 October 2012 21:54:19 Thomas Schatzl wrote:
Basically the difference between armel and armhf are
- fpc cannot create valid armhf shared libraries
Other problems common to both (just from interpreting the testsuite
results, filtering known failing tests):
-
I have long understood that each stable release of freepascal is made to
be compilable with the previous release but at a quick glance at the
website I couldn't seem to spot any official statement of this. Is it
indeed supported to compile a stable release with the previous stable
release and
Thomas Schatzl wrote:
Last time I tried compiling with -Cfvfpv2 or 3 the compiler did not
cycle, so I could not test further. Has been some time, and this was
native compilation.
Last I heard cycling goes fine but FPU options don't get passed down
to other parts of the build process leading
I am involved in a project called raspbian to produce a hard-float
derivative of debian for the raspberry pi. Within this port we had
problems with floating point exceptions while running the compiler.
These problems were tracked down by masta (a freepascal upstream
developer) to reversed
peter green wrote:
an IMX53 quickstart board running
That should have said running 3.2.0-2-mx5
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
shawn wrote:
http://sourceware.org/ml/libc-ports/2012-06/msg00021.html
I quote: ARM VFPv3 and VFPv4 do not support trapping floating-point
exceptions;
VFPv2, VFPv3U and VFPv4U do. The lack of support causes the glibc
math/test-fenv test to fail on VFPv3 and VFPv4 systems
Am I correctly
Is it possible to tell the inline assembler to output something to the
resulting assembler file even though it doesn't recognise the opcode?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Jonas Maebe wrote:
On 20 Mar 2012, at 23:43, peter green wrote:
I attatch a patch which adds support for armhf to freepascal.
Thanks!
Armhf reffers to arm with the VFP hardfloat variant of EABI. The
defaults are setup to
be suitable for debian armhf (armv7 vfpv3_d16).
Are they Debian
Unfortunately just after I sent the mail what I thought was a minor
problem in the build system turned out to be more serious than I
thought, namely cthreads is crashing at initalisation time. I really
need to figure out why before merging this patch is considered.
Ok solved that issue, it
Jonas Maebe wrote:
On 20 Mar 2012, at 23:43, peter green wrote:
I attatch a patch which adds support for armhf to freepascal.
Thanks!
Unfortunately just after I sent the mail what I thought was a minor
problem in the build system turned out to be more serious than I
thought, namely
Jonas Maebe wrote:
The compiler should find the crt*.o files on its own, especially if you create
a special compiler binary for the hard float ABI (there is no point in creating
a special binary if you still need to separately specify a bunch of additional
options to get the correct
peter green wrote:
The bad news is that a number of testcases are still failing. Next on
my list is 16 singles.
Ok that was easy, a small logic flaw in my code was preventing a
parameter being correctly assigned to the last available single
precision register when it should have been
I can now successfully pass doubles to/from C functions on armhf. I've
written a test program that passes lots of different combinations of
single/double/longint/int64 to C code and all combinations that do not
involve singles are working.
It would also be helpful to add this test to
The buildfaq claims that OPT= will add parameters to every compiler
commandline. Unfortunately it doesn't seem to actually do that. The
options are added when building the compiler and RTL but it seems they
aren't added when building fpmake.
This is a problem for me as to successfully build
Okay, it is quite unlikely that the register allocator itself ignores
such an interference, so you may be rigth it tries to spill but
nothing happens.
Ok that wasn't the issue but you were right about not being the register
allocator.
Turns out the actual cause was a one character typo
Daniël Mantione wrote:
Please use the command line option -sr to check the generated code
before register allocation.
Done and attatched.
You can likely find the cause in there.
The code with imaginary registers looks correct to me. It seems to load
each parameter into a seperate even
Then a register is spilled, i.e. replace by a location in memory. This
may be possible without new registers:
mov ireg30d,ireg29d- mov ireg30d,[ebp-40]
... but in some cases a help register is needed:
mov ireg30d,[ebp+20] - mov ireg99d,[ebp+20]
While testing my armhf porting work (which I will send on request, including it
in this mail seems to make it too big for the list to accept) I came across a
case
where parameters were passed incorrectly to a function with a large number of
parameters (14 single, 1 double). Initially I thought
I can now successfully pass doubles to/from C functions on armhf. I've
written a test program that passes lots of different combinations of
single/double/longint/int64 to C code and all combinations that do not
involve singles are working.
A patch with the current state of the work is
Jonas Maebe wrote:
You can give S1, S3, S5 etc different super register numbers ( $1F,
so they don't conflict with the super register numbers for D0..D31).
As long as you don't change the code in
tarmcgarm/Tthumb2cgarm.init_register_allocators() to explicitly tell
the register allocator that
I've made some progress on armhf porting, i've added the nessacery
frameworks (vfpv3_d16 FPU target, EABIVFP ABI target, FPC_ARMHF define)
and made a start on actually implementing the new ABI. I decided to
start with function results.
However i've now reached a problem which has me stumped.
Florian Klaempfl wrote:
Am 11.03.2012 12:01, schrieb peter green:
It appears to me (i'm not an expert on arm assembler and I can't seem
to find any documentation on FPA) that FPC is generating FPA
instructions even though the FPU is set to a VFP type. What i'm really
struggling to work out
Where is the FPU set to a VFP type?
I set it in code.
Defining FPC_ARMHF selects a new version of system_arm_linux_info
which sets the ABI to abi_eabivfp.
That in turn triggers a block of code that I added to options.pas which
sets the default fpu to fpu_vfpv3_d16 and errors out if the
Then I suggest you simply debug it like any other code: first set a breakpoint in options.pas where the fpu type should be set, and verify that it is in fact set.
I'm pretty sure it is getting set because I use it in generating the
assembler command line and i'm using an assembler wrapper that
Just set a breakpoint in the place where one of the offending instructions is
generated, found via grep. E.g., the only place where an LDF is generated is in
arm/cgcpu.pas (in a_loadfpu_ref_reg).
Hmm, when I grepped for the first and most prolific problem instruction
(mvfd) I didn't find
Are you saying that VFP registers are treated as multimedia registers and not
as FPU registers? If so presumablly that mean I should be using LOC_MMREG and
not LOC_FPUREG as the location for parameters and return values?
Yes.
Thank you for your help so-far, i'm gradually making
NR_S0NR_D0: they can be identified by the sub type. Further, one can
perfectly assign NR_S1 to any location explicitly.
Umm, my copy of narmcon.pas contains the following.
NR_S0 = tregister($0406);
NR_S1 = tregister($0406);
NR_D0 = tregister($0407);
I can see how the compiler can
Maybe this will help you:
http://wiki.freepascal.org/FPC_New_Features_2.6.0#Support_for_VFPv2_and_VFPv3
Thus additionially defining -Cparmv6 might allow the build to be
completed.
It didn't.
I did find the issue though, it seems freepascal wasn't passing a fpu
type parameter to the
I decided to take another look at the freepascal armhf issue and decided
that the first step would be to build freepascal with vfp enabled but
still the softfloat ABI then once that was working.
(note: i'm currently working on upstream fpc svn, if/when I get things
working reasonablly on
But this seems to be be a propriety Microsoft definition while AFAIK,
ANSI denotes American National Standards Institute.
While ANSI does denote american national standards institute in general
it doesn't really mean that in this context.
A windows machine has two main code pages in use (both
First a bit of background, on arm ebi gcc has three options for
-mfloat-abi
soft: do all floating point in software, ignore the fpu type selection
softfp: use the selected fpu type but use the same calling conventions
as soft (that is parameters are passed using integer registers). This
gives
tags 636802 +patch
thanks
Note: jonas's reply was only posted to fpc-devel, not to the debian bug
report , a copy can be found at
http://lists.freepascal.org/lists/fpc-devel/2011-August/025444.html
Jonas Maebe wrote:
Is there a standard for multiarch library path locations and names?
Armin Diehl wrote:
I need some hint regarding opening a serial (ttyUSB) port using the
unit serial. Minicom works fine under my user id. When i call
SerOpen('/dev/ttyUSB0'), fpopen blocks forever. When i first start
minicom on that port, SerOpen and all other functions of serial.pp
works
reassign 636802 fpc
thanks
From my testing on armel I now belive that the issue causing the
lazarus build failures is a problem with freepascal and multiarch. I
haven't tried to troubleshoot the issue on powerpc or sparc as I don't
have access to them but I presume it is the same issue.
On
Freepascal has been failing sometimes with einouterror file not found
on armel buildds but i'm not really seeing any pattern to the failures
either in terms of upstream versions or in terms of buildds
2.4.0-2 was successfully built on muscat
2.4.0-3 failed on arnold
2.4.0-4 failed on arnold
Riku Voipio wrote:
Qemu allows unaligned memory accesses, which do not always work on real
hardware, especially on armv5 and other older arms.
Do you know specifically how the debian buildds handle unaligned
accesses? do they fix them up? do they generate a bus error? do they let
them go
Mark Morgan Lloyd wrote:
Riku Voipio wrote:
On Thu, Jun 30, 2011 at 03:33:36PM +0100, peter green wrote:
The current FPC package builds fine in qemu for me. I will attempt
to try on some real hardware too when I get a chance.
Qemu allows unaligned memory accesses, which do not always work
Jonas Maebe wrote:
On 30 Jun 2011, at 19:04, peter green wrote:
Mark Morgan Lloyd wrote:
Riku Voipio wrote:
On Thu, Jun 30, 2011 at 03:33:36PM +0100, peter green wrote:
The current FPC package builds fine in qemu for me. I will attempt to try on
some real hardware
I don't think that people will be happy if the compiler just deletes
their ppus if it can't read it for any reason. The compiler cannot know
if it can recreate the ppu when it deletes it.
Can't it just be made to treat a damaged/unreadable ppu in the same way
as an outdated or incompatible
in the freepascal programmers guide it says For all other processors
which support floating point operations, the extended type is a nickname
for the type which supports the most precision. A few points about this
1: is there a table anywhere of the size of extended on different
platforms? if
Debian Lenny has switched to armel rather than arm.
Lenny is availible for both arm and armel.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Well, I think that the compiler could be shared between a native code
and bytecode machine.
I think the frontend (parsing the language into a tree structure) can
certainly be shared, i'm not sure about the further back stages.
Bytecode environments are certainly very different from native code
For best backward compatibility, I would say Copy, Length, Pos etc
should work by character based by default.
The thing is we can't reasonablly provide functions based on what a user
would see as a character because doing so would require huge lookup
tables (one user visible character != one
I fully agree with you. I would like the object oriented way of strings
also - but I stopped asking for that ;) There are a lot of advantages
over the small amount of disadvantages.
Which object orientated way of doing strings?
As I see it there are three main ways of doing variable length
Check again...
I have just checked the manual and I don't see anything I can use to
make sure my custom type starts at a predictable state initially
(nessacery so they assignment operator can safely clean up before making
the assignment). Nor do I see anything to do automatic clean up when
This has been discussed before. Automatic conversion to/from
ansistrings will always be to/from system encoding. If you want
another encoding than the system encoding you will have to do a manual
conversion.
Actually you as the application developer can control how conversions
between
All I really use 'libc' for is to retrieve the user name and group
name from the user and group id's of files. As I said, it's not
critical, I can always display the id's only. Or maybe parse the
/etc/groups and /etc/passwd files to get the names, but I heard that's
not very accurate for some
Felipe Monteiro de Carvalho wrote:
Hello,
Today I took a look at what would be necessary to implement
controlling the output of the widestring manager, and implementing
this looks rather trivial.
The only thing we need is a switch, to control if widestrings should
be converted to the current
Using the following example program and compiling with 'fpc -al
wstest.pas' under Linux to see the assembler file (not that I can
remember anything of how assembler works). Looking at the asm code I
see a call to FPC_WIDESTR_INCR_REF which I assume confirms that
WideStrings under Linux using
And a single code comparison can be seen here... FPC code is on the right.
http://www.stevetrefethen.com/files/ppcomp.htm
Reading the description carefully it seems like he has modified the
delphi code to look more like the FPC code.
In many cases two people trying to implement the
Non trivial Delphi GUI apps also quickly rise to 1.5MB
lazarus may produce apps that are size comparable with those from the recent
versions of delphi but those are also megabloat compared to those produced by
the older versions of delphi.
___
They don't have to: the compilers/interpreters for these languages are
written in C. All they need to do in the worst case is compile a small
stub. For Pascal, the situation is not so simple, as there is no
connection
with C whatsoever.
well there is nothing to stop you writing stubs in
PPC is getting dropped in Fiesty, they will no longer officialy support
PPC.
well they are making it no longer an official architecture but they aren't
dropping it completely so pressure still needs to be kept up for them to build
it on powerpc ;)
What does the compiler do when translating procedure ... message ?
I need to know this as I want to create a non-GUI workalike of the
TApplication class that can do things like TTimer
TThread.Synchronize, Message events, etc, using Windows messages in
Windows (for testing purpose) and
What's wrong with
type
tmywidestring = type array of widechar;
a number of things
1: afaict it lacks the automatic refcounting/copy on write semantics of strings
2: it doesn't allow specification of the allocators/deallocators which causes
problems for its safe passing to dlls etc
currently there is some demand for a fast widestring type on windows and i
suspect there will be requirements for more string types in the future.
So i make a proposal for a new syntax that will allow string types to be
created easilly in libraries or user code.
my proposal is a statement like
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Daniël
Mantione
Sent: 04 February 2007 00:09
To: FPC developers' list
Subject: Re: [fpc-devel] strings: a proposeal
Op Sun, 4 Feb 2007, schreef peter green:
my proposal is a statement like
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Aleš Katona
Sent: 07 January 2007 09:55
To: FPC developers' list
Subject: Re: [fpc-devel] Incompatibilities between win32 windows unit
andwince windows unit
On Ne, 2007-01-07 at 00:23 -0200, Felipe
I'm not particularly happy with pascalization of direct interfaces
myself.
me neither, my understanding of this problem is that borland pascalised the
windows unit in delphi and freepascal followed suite for win32.
but for whatever reason the same was not done for wince.
since wince support
Btw, see
http://www.sun.com/software/opensource/java/faq.jsp#g4
some discussion on why one would choose for example GPL + Classpath
exception (an amendment text from the Classpath project) vs LGPL.
These two
seem equivalent, but the 1st means that one can include in some Linux
distros
On the long run I am interested in making (embedded) FPC programs run on
(our own) ARM-hardware.
I only found notice about FPC programs for PDAs. Am I right assuming
that there is no special problem using a displayless ARM9 device (like a
slug) for FPC programs ?
afaict the slug is quite
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Marco van de
Voort
Sent: 16 December 2006 11:17
To: FPC developers' list
Subject: Re: [fpc-devel] fdRead?
Hi. Can someone please tell me what the idea behind fdRead was?
Roughly 1.0.x
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Michael
Schnell
Sent: 15 December 2006 11:59
To: FPC developers' list
Subject: Re: [fpc-devel] help with softfloat for arm big endian
crosscompiler
however some hardware is wired up for big
Hola, most modern ARM cpu's support big endian, that is not the point.
Question is how many an big endian platforms exists, and this is not so
popular, because even if you switch the cpu to big endian, the underlying
hardware remains little endian (with the cpu doing the conversion). This
Well, the linked list would be freed (or the first item of it enlarged
to the total size, depending on implementation details).
Still, the peak memory use will twice the size, won't it?
sure but unless you are very lucky a call to reallocmem also means
alocate-copy-deallocate.
The thing is full of this. Problem is, each OS and platform has slightly
different arguments and return types AND we need to be flexible enough
to support more than one threading implementation on same platform too
(so no godamn ifdefs).
use INT64 everywhere?
5356 - does not compile under win32 (ppc1 does not stop compiling
pp.pas [neither fails, nor succeeds])
(memory usage in process list freezes at 31444 Kb)
what starting compiler are you using?
___
fpc-devel maillist -
Currently we have been developing on FPC for both Windows and Linux and we
have noticed that socket communications are not working correctly under
Linux environments.
please define what you mean by not working correctly, preferally with a test
app
I have also been advised that the netdb has
CmdLine as property will be great, but I found that property
getter/setter need to be declared before property declaration in the
interface part. This will garbage a global namespace with private
getters/setters.
Is it possible to make compiler to accept getters/setters not
declared in the
i'd like a way to tell the compiler not to allow implicit conversions
between certain types (e.g. ansi/shortstrings and widestrings) this would
make it much easier to clean up existing code that carelessly converts
between two sort of but not very compatible types.
one trick if you wan't to keep a type but redefine the operators on it is to
wrap it in a single element record.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Marc
Weustink
Sent: 14 October 2006 16:42
To: FPC developers' list
Subject: Re:
In the case of wrapper integers in records, are 4-byte records handled as
efficiently by the compiler as 4-byte integers? I suspect it's
some radically
different code that handles it.
test it?
___
fpc-devel maillist -
I'm not sure what
WideString holds. Maybe UTF-16? Or a limited UTF-16 with only 2 bytes
characters.
UCS-2. Basically this is UTF-16 with only 2-byte characters, allthough
there are small differences in the high regions; UCS-2 is code
points $0..$, while UTF-16 has facilities to allow
Changing type to something which is not a descendant (and thus
incompatible) seems useless and always dangerous to me, so should be
forbidden if possible.
useless yes, dangerous if not carefull yes but its the number one way for
bypassing protected ;)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Micha
Nelissen
Sent: 01 October 2006 21:41
To: FPC developers' list
Subject: Re: [fpc-devel] Language extension: absolute for classes
peter green wrote:
Changing type to something which
i'm guessing (i could be wrong) that you need to link in libstdc++
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Ivo
Steinmann
Sent: 23 September 2006 19:48
To: FPC developers' list
Subject: [fpc-devel] Linking problem
Hello all
I tried to
...which makes it impossible to use streams for anything derived from
Tcomponent, which is really a lot. I don't think we should break this
feature to allow broken code to work.
BTW even borland themselves seemed to promote its use for storing pointers
from delphi 3 help:
Tag has no
I'd like to propose change TComponent.Tag type from longint to PtrInt.
I know it's not a good programing practice, but sometimes this property
can be used to hold pointers.
In 32bit there's not many problems since pointer and longint have the
same size, but the thing changes in 64 bit.
The
I would love to be a maintainer and build .deb files, however I do not
own a 64 bit CPU and can't afford one at the moment because it would
also mean a new motherboard and RAM too, so that crosses me out pretty
much. In fact, I really would love to see Free Pascal packages in the
Ubuntu
1 - 100 of 156 matches
Mail list logo
