make[4]: /home/me/Programs/fpc/cross_fpc/cross/bin/i686-cygwin-as:
Command not found
The error is very clear, do you have the assembler in the indicated
directory? Make sure the result of building binutils have i686-cygwin-
prefix. Otherwise, you have to specify -XP compiler option to specify
I prefer doing this manually, syntax conversion is easy, but library design
is totally different.
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/TPLY-tp3235828p3236641.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
Hi,
Language Reference, Section 1.4 Identifiers says:
Identifiers consist of between 1 and 127 significant characters
(letters, digits and the underscore character), of which the
first must be an alphanumeric character, or an underscore (_).
Should alphanumeric be alphabetic here? Since
On Tue, 26 Oct 2010, Vladimir Zhirov wrote:
Hi,
Language Reference, Section 1.4 Identifiers says:
Identifiers consist of between 1 and 127 significant characters
(letters, digits and the underscore character), of which the
first must be an alphanumeric character, or an underscore (_).
On 10/26/2010 10:18 AM, leledumbo wrote:
make[4]: /home/me/Programs/fpc/cross_fpc/cross/bin/i686-cygwin-as:
Command not found
The error is very clear, do you have the assembler in the indicated
directory? Make sure the result of building binutils have i686-cygwin-
prefix. Otherwise,
2010/10/26 patspiper patspi...@yahoo.com
The buildcrossbinutils.sh script produces i686-mingw32- binaries only (no
i686-cygwin-), and yet, FPC 2.4.2 cross compiles without any problem. What
is different about 2.5.1?
Probably 2.5.1 contains assembler files, so it needs an assembler, 2.4.2
A bug may show anytime anywhere, but the built in ref counted string
types are AFAIK thread safe what concerns the ref count per se. I
suspect a subtle flaw in the client code is more probable.
No, it is a compiler bug. The same code works 100% perfectly on
Windows using Delphi, as well as on
Am 26.10.2010 10:55, schrieb Tobias Giesen:
A bug may show anytime anywhere, but the built in ref counted string
types are AFAIK thread safe what concerns the ref count per se. I
suspect a subtle flaw in the client code is more probable.
No, it is a compiler bug. The same code works 100%
Hi,
I was wrong, UniqueString does not help after all. I am now using an
extended version of the heaptrc unit to show the reference count (and
string value) for unfreed WideStrings and they usually have 1 as a
reference count.
Will keep you posted.
Cheers,
Tobias
On 10/26/2010 05:48 PM, Jonas Maebe wrote:
On 26 Oct 2010, at 16:38, patspiper wrote:
i686-mingw32-as is present in the crossbinutils bin folder. But the
error concerns i686-cygwin-as...why would it ask for the assembler
with a i686-cygwin prefix?
Because that's probably the version that
On 26 Oct 2010, at 17:40, Marco van de Voort wrote:
In our previous episode, Jonas Maebe said:
OPT=-XPi686-mingw32- -FD/full/path/to/crossbinutils
IIRC it is wiser to use the variables (CROSSBINDIR and CROSSBINUTILSPREFIX
or so, see buildfaq), because these are then only applied to the
On 26 Oct 2010, at 21:28, Tobias Giesen wrote:
Upon exit, the memory does seem to be freed correctly now according to
heaptrc. But MacOS stops giving memory to the app after a while and
then it quits.
Could it be that the memory manager has been changed since FPC 2.2 and
is now more
Hi Jonas,
thanks very much!!!
I am sorry for the wrong things that I wrote. Now I can clearly see that
the memory is not lost on the FPC heap. The total heap size doesn't even
change at all. So there's no difference with CMem either.
More work to do ...
Cheers,
Tobias
13 matches
Mail list logo
