Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd:
I'm currently cross-compiling the MacOS RTL for PPC on a PC. I've
fixed some trivial issues that had crept in since this was last
maintained, some of which affect other targets, but am stuck at the
errors below.
/usr/local/src/fpc/fpc-trunk/comp
Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd:
I'm currently cross-compiling the MacOS RTL for PPC on a PC. I've
fixed some trivial issues that had crept in since this was last
maintained, some of which affect other targets, but am stuck at the
errors below.
/usr/local/src/fpc/fpc-trunk/comp
> -Message d'origine-
> De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
> boun...@lists.freepascal.org] De la part de Sven Barth
> Envoyé : lundi 10 décembre 2012 16:37
> À : fpc-devel@lists.freepascal.org
> Objet : Re: [fpc-devel] Revisiting MacO
Sven Barth wrote:
Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd:
I'm currently cross-compiling the MacOS RTL for PPC on a PC. I've
fixed some trivial issues that had crept in since this was last
maintained, some of which affect other targets, but am stuck at the
errors below.
/usr/local/src
devel] Revisiting MacOS for PPC (and possibly 68K)
Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd:
I'm currently cross-compiling the MacOS RTL for PPC on a PC. I've
fixed some trivial issues that had crept in since this was last
maintained, some of which affect other targets, but am stuc
Am 10.12.2012 17:05, schrieb Mark Morgan Lloyd:
Sven Barth wrote:
Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd:
I'm currently cross-compiling the MacOS RTL for PPC on a PC. I've
fixed some trivial issues that had crept in since this was last
maintained, some of which affect other targets, bu
Sven Barth wrote:
Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd:
I'm currently cross-compiling the MacOS RTL for PPC on a PC. I've
fixed some trivial issues that had crept in since this was last
maintained, some of which affect other targets, but am stuck at the
errors below.
/usr/local/src
Am 10.12.2012 17:24, schrieb Mark Morgan Lloyd:
Sven Barth wrote:
Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd:
I'm currently cross-compiling the MacOS RTL for PPC on a PC. I've
fixed some trivial issues that had crept in since this was last
maintained, some of which affect other targets, bu
Sven Barth wrote:
You can pass "CROSSOPT="-st"" to the call of make.
You are nearly at that stage though as the compiler has already parsed
the unit, generated the assembler code tree and now is about to output
the assembly file (system.s) and call the assembler. And while the step
of output
Sven Barth wrote:
Am 10.12.2012 17:24, schrieb Mark Morgan Lloyd:
Sven Barth wrote:
Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd:
I'm currently cross-compiling the MacOS RTL for PPC on a PC. I've
fixed some trivial issues that had crept in since this was last
maintained, some of which affec
Mark Morgan Lloyd wrote:
Not necessarily. It seems to be related to something "external".
OK, I get that now that I'm looking at the functions etc.
You could try the following by adjusting the compiler source: before
the internalerror (in compiler/powerpc/agppcmpw.pas)
Noting that this is
Mark Morgan Lloyd wrote:
So I suppose that the next thing to do is to (use Lazarus to) look at
the conditions earlier in the compiler where AT_NONE is being inserted
in the list.
It's putting a significant number of AT_NONE entries into the table, and
the first one it tries to take out (whic
On 10.12.2012 21:06, Mark Morgan Lloyd wrote:
Mark Morgan Lloyd wrote:
So I suppose that the next thing to do is to (use Lazarus to) look at
the conditions earlier in the compiler where AT_NONE is being inserted
in the list.
It's putting a significant number of AT_NONE entries into the table,
11.12.2012 1:27, Sven Barth пишет:
It's putting a significant number of AT_NONE entries into the table, and
the first one it tries to take out (which obviously isn't the first
entry in the list) causes the internal error. When being put in, this
entry had a call stack like
#0 TASMDATA__REFASMSY
Sergei Gorelkin wrote:
11.12.2012 1:27, Sven Barth пишет:
It's putting a significant number of AT_NONE entries into the table, and
the first one it tries to take out (which obviously isn't the first
entry in the list) causes the internal error. When being put in, this
entry had a call stack lik
15 matches
Mail list logo