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 offset
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 x>1 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 d
Hans-Peter Diettrich wrote:
2) Formatted numbers, as enterd by the user (maybe by copy&paste from
other applications), can have various encodings. Before a conversion
into binary values I'd remove all unexpected characters, except for
the last (rightmost) '.' or ',', which then becomes the deci
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 armh
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 fpc_2.6.4
>> 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
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.
Sinc
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 hel
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 - fpc-devel@lists.freepascal.
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
http://lists.freepascal.org/cgi-bin/mailman/listinfo/
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 a
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 would
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 d
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 ot
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 fa
Joost van der Sluis wrote:
On 08/09/2013 07:07 PM, Jonas Maebe wrote:
On 09 Aug 2013, at 18:46, Joost van der Sluis wrote:
Thing is that I'm trying to get fpc 2.6.2 working on the new
arm-target of Fedora (armv7, hardware float, little endian).
The EABI with hardfloat is not supported at al
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 tar
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 (if
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 loc
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 t
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 inte
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
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 logic
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
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 see
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 behaviour)
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
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 fp
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 th
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. And with
S30,$04,$06,$0F,s20,0,0
Should be
S30,$04,$06,$0F,s20,0,0
Doh seems I pasted the wrong line twice, it really should be
S30,$04,$06,$0F,s30,0,0
Please don't change it in trunk at the moment through because my armhf
porting work makes a lot of other changes to armreg.dat and I doubt this
b
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 i
The algorithm used is called "iterated register coalescing", an
advanced form of graph colouting and was designed by Andrew W. Appel.
He describes in detail in his book "Modern Compiler Implementation in C".
Thanks, I think i'll grab a copy from the uni library tomorrow.
Basically the regi
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]
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 numbere
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 attatche
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
NR_S0<>NR_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 ca
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 progr
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
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
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 t
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
struggl
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.
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 ass
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 armhf
>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 (b
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
gi
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?
Multi
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 fine.
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 a
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
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
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 si
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 a
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?
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 in
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
Michael Schnell wrote:
It will at best be "friendly old school behaviour which works most of
the time, but which fails as soon as the strings are not completely
normalised because then you can have decomposed characters and
whatnot" (which in turn easily leads to security holes due to
inco
Because a Pascal compiler parses the interface section of an unit only
once, ...
IMO what would fix a lot of the problem would be a "cross unit forward
declaration", that is a way to tell a compiler "this type is a class
type declared in unit x that is all you need to know for now" (afaict
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 th
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 str
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 ans
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 lo
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 FP
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 same
Felipe Monteiro de Carvalho wrote:
Hi,
I would like which would be the theoritical way that Free Pascal could
support an always utf-8 encoded string (if it will be supported). With
that I mean a string which when set by code is converted from
widestring to utf-8 in despite of any environmental c
> 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.
___
fpc-
> 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 i
> > The graph unit is pretty generic in this respect. You indeed only need
> > to implement putpixel, getpixel, graphics mode detection, setting a
> > graphic mode, setting and getting colour palette entries for indexed
> > modes, and closing down the graphic system again. But it's perfectly
> 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 ;)
> Just like to say, that I noticed the other day that Freepascal 2.0.4 has
> made it to the Ubuntu Feisty Universe repositories. Ubuntu Feisty is
> expected to be out in April, but has never had Freepascal in it's
> repositories before.
>
> I think this is great news for Freepascal...
FINALLY
lo
> 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 pur
> 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
__
> -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, sch
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
> 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 suppo
> -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 -020
> 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
> distr
> 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 qu
> -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
> -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 fo
> 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). Th
> > 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 - fpc-devel@lists.freepascal
> 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
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.
1 - 100 of 180 matches
Mail list logo
