[fpc-devel] Revisiting MacOS for PPC (and possibly 68K)

Sven Barth pascaldragon at googlemail.com
Mon Dec 10 17:05:22 CET 2012


Am 10.12.2012 16:56, schrieb Pierre Free Pascal:
>
>> -----Message d'origine-----
>> De : fpc-devel-bounces at lists.freepascal.org [mailto:fpc-devel-
>> bounces at lists.freepascal.org] De la part de Sven Barth
>> Envoyé : lundi 10 décembre 2012 16:37
>> À : fpc-devel at lists.freepascal.org
>> Objet : Re: [fpc-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 stuck at the
>>> errors below.
>>>
>>> /usr/local/src/fpc/fpc-trunk/compiler/ppcXppc -Ur -Tmacos -Ppowerpc
>>> -XPpowerpc-macos- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../powerpc -FE.
>>> -FU/usr/local/src/fpc/fpc-trunk/rtl/units/powerpc-macos -dpowerpc
>>> -dRELEASE  -Us -Sg system.pp
>>> text.inc(1789,14) Warning: Implicit string type conversion from
>>> "AnsiString" to "UnicodeString"
>>> text.inc(2013,44) Warning: Implicit string type conversion with
>>> potential data loss from "UnicodeString" to "AnsiString"
>>> system.pp(481,2) Warning: User defined: To be implemented - using
>>> GetProcessInformation???
>>> system.pp(571) Fatal: Internal error 2003090901
>>> Fatal: Compilation aborted
>>> make[2]: *** [system.ppu] Error 1
>>> make[2]: Leaving directory `/usr/local/src/fpc/fpc-trunk/rtl/macos'
>>>
>>> Allowing that system.pp ends at line 570, I presume that something
>>> after  line 481 is confusing the compiler. Any suggestions would be
>>> appreciated.
>>>
>> Not necessarily. It seems to be related to something "external".
>>
>> You could try the following by adjusting the compiler source: before the
>> internalerror (in compiler/powerpc/agppcmpw.pas) add a
>> "writeln(tasmsymbol(p).typ)" and maybe also a "AsmFlush" so that the
>> assembler file up to the error will be written so you can see in which
>> function the problem exists.
>>
>> You could also debug the compiler (copy the command line from the
>> Makefile's output) when compiling the system unit and place a breakpoint
>> on the internalerror and then investigate the "p" variable.
>    I was wondering how many of you know/use the
> gppc386 trick?
I did not know that, but I personally prefer debugging using Lazarus :)

Regards,
Sven



More information about the fpc-devel mailing list