This thread is a summary of intermittent experience over the last year or so with Lazarus running natively on various platforms. I hope to cover ARM, PPC, SPARC and (for completeness) x86 on Linux (Debian v5 "Lenny"), possibly also some older Windows OSes on x86 (NT, W2K); I'm afraid that I don't have an x64 system which I think would cover all currently-supported CPUs.

Mattias, noting your

0.9.29 with fpc 2.4.0 or higher.

I'll work with sources from svn. This might mean that I'm a day or so behind in some cases since some of the older machines will take more than a day doing a full build.

ARM (armel) on Debian "Lenny"
-----------------------------

Debian's transition between arm and armel was a bit painful, so while I was able to build Lazarus apps about 18 months ago I've since had a bit of a hiatus. Starting with FPC 2.2.2 binaries I was able to generate a 2.4.0 as below:

-----8<-----
I can confirm that I can build FPC 2.4.0 to run under Debian "Lenny" on an ARM-based system (Cisco/Linksys NSLU2 "Slug") using

make 'NOGDB=1' 'OPT=-dFPC_ARMEL -CfSOFT' all

This appears to be OK to the extent that it can compile Lazarus 0.9.28.3, although my initial attempt ("make all") bombed but for some reason "make 'OPT=-vt' all" was OK.

If starting with a binary of 2.2.2 it's necessary first to generate 2.4.0 using 'OPT=-CfSOFT'. Obviously the amount of memory limits compilation and in particular linkage speed. I've not tried later versions yet.
----->8-----

I know that I can do a basic (i.e. without bigide) compile of 0.9.28.2, except that there's an intermittent problem with this where the compiler fails with a numeric backtrace, restarting the make picks up where it left off. I think this is due to the system I'm running only having a minuscule amount of RAM, but something is not handling that very gracefully. Jonas has suggested that I update the compiler but I'll try to get this set of trial builds out of the way first.

0.9.28.2 builds (without bigide) and gives me a runnable Lazarus, I've not tried building a project. Access violation while exiting- ignoring that for the moment. 0.9.28.3 behaves the same.

Building 0.9.29 fails early with a consistent fault:

$ make all
make -C lcl all
make[1]: Entering directory `/usr/local/share/lazarus-trunk/lcl' /bin/rm -f units/arm-linux/alllclunits.ppu
/bin/mkdir -p units/arm-linux
/usr/local/bin/ppcarm -gl -Fu. -Funonwin32 -Fuforms -Fuwidgetset -Fu/usr/local/lib/fpc/2.4.0/units/arm-linux/rtl -Fiinclude -FE. -FUunits/arm-linux -darm alllclunits.pp
Free Pascal Compiler version 2.4.0 [2010/08/21] for arm Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux for ARMEL
Compiling alllclunits.pp
Compiling lclversion.pas
Assembling lclversion
Compiling lclstrconsts.pas
Writing Resource String Table file: lclstrconsts.rst Assembling lclstrconsts
Compiling fpcadds.pas
Assembling fpcadds
Compiling lazlinkedlist.pas
Assembling lazlinkedlist
Compiling dynhasharray.pp
Compiling lclproc.pas
Compiling avglvltree.pas
Assembling avglvltree
Compiling fileutil.pas
Compiling masks.pas
Assembling masks
Assembling fileutil
Compiling lcltype.pp
Assembling lcltype
Compiling ./widgetset/wsreferences.pp
Assembling wsreferences
Fatal: Compilation aborted
An unhandled exception occurred at $00086C50 :
EAccessViolation : Access violation
$00086C50
$000F6A30
$00140F5C
$0011FF78
$0013648C
$0013FDA0
$00140950
$0011FF78
$0013648C
$0013FDA0
$00140950
$0011FF78
$00024370
$00008304

make[1]: *** [alllclunits.ppu] Error 217
make[1]: Leaving directory `/usr/local/share/lazarus-trunk/lcl' make: *** [lcl] Error 2

Since this one IS a consistent error I can run it under gdb:

(gdb) run
Starting program: /usr/local/bin/ppcarm -gl -Fu. -Funonwin32 -Fuforms -Fuwidgetset -Fu/usr/local/lib/fpc/2.4.0/units/arm-linux/rtl -Fiinclude -FE. -FUunits/arm-linux -darm alllclunits.pp
Free Pascal Compiler version 2.4.0 [2010/08/21] for arm Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux for ARMEL
Compiling alllclunits.pp
Compiling dynhasharray.pp
Compiling lclproc.pas

Program received signal SIGSEGV, Segmentation fault. 0x00086c50 in ?? ()
(gdb) bt
#0 0x00086c50 in ?? ()
(gdb)

I'm going to leave this until the end of the day in case anybody's got any comments. Unless anybody's got any better suggestions I will then apply Jonas's modified syscall.inc to 2.4.0 and then do another build of 0.9.28.3 to see if the couple of niggles are resolved, after that I'll retry 0.9.29.

Why don't you build your compiler with -O- -gl?

Henry

I thought I had but I'll check... the version of the compiler I'm running was built with make NOGDB=1 OPT=-gl -vt -dFPC_ARMEL -CfSOFT all which I've generally found to give usable backtraces etc. Is adding -O- a useful precaution?

Hello,

I think that this should be placed in fpc-pascal or fpc-devel mailling lists. It's a problem with the compiler, not Lazarus.

thanks,

Well, I'm not sure which optimisations are debugger safe, so I usually disable them all. I pass OPT="-dFPC_ARMEL -O- -gl" and that seems to work for the traces. I don't know if it'll help in your case, though.

Henry

Felipe Monteiro de Carvalho wrote

Hello, I think that this should be placed in fpc-pascal or fpc-devel mailling lists. It's a problem with the compiler, not Lazarus.

I disagree. While the problem is possibly with the compiler, he is reporting on his efforts to build lazarus. If someone has succeeded before, they are likely to be subscribed to this list, and people will search this list to see if it's possible, to get make options, etc.

It wouldn't hurt to copy fpc-pascal and fpc-devel. It also wouldn't hurt if you could actually quote a relevant message so that we can see who you are replying to without looking at the headers of the message.

Henry

OK. I'll apply Jonas's fix and recompile like that. I may be some time.

I agree that it's a marginal case, but I did raise it in fpc-devel (4th October) which is where Jonas suggested a possible fix based on something he'd recently done.

I'm going to rebuild FPC 2.4.0 with Jonas's fix and -O-, build 0.9.28.3 to see whether I still get an intermittent failure during compilation, note whether I still get a predictable failure on quitting Lazarus, and then move back onto 0.9.29.

Using the modified 2.4.0 Lazarus builds (make all) on armel without problems. However I still get a failure during exit that I don't believe I've seen on other architectures:

TMainIDE.ParseCmdLineOptions:
PrimaryConfigPath="/home/markMLl/.lazarus"
SecondaryConfigPath="/etc/lazarus"
NOTE: miscellaneous options file not found - using defaults TMainIDE.DoLoadLFM Creating designer for hidden component of /home/markMLl/unit1.pas
TMainIDE.DoOpenProjectFile Form1:TForm1 TDesigner
TApplication.HandleException Access violation
Stack trace:
$005D3AF0 SEARCH, line 4407 of project.pp
$005D36F8 TPROJECT__UPDATEUNITCOMPONENTDEPENDENCIES, line 4485 of project.pp
$00082BA8 TMAINIDE__UNITCOMPONENTISUSED, line 7074 of main.pp $00082568 TMAINIDE__CLOSEUNITCOMPONENT, line 6948 of main.pp $00087E78 TMAINIDE__DOCLOSEEDITORFILE, line 8323 of main.pp $0008E57C TMAINIDE__DOCLOSEPROJECT, line 9831 of main.pp $000694D4 TMAINIDE__MAINIDEFORMCLOSEQUERY, line 1720 of main.pp $00092134 TMAINIDE__QUITIDE, line 10666 of main.pp $00072F0C TMAINIDE__MNUQUITCLICKED, line 3428 of main.pp $005AB748 TIDEMENUITEM__MENUITEMCLICK, line 551 of menuintf.pas $005AF8E0 TIDEMENUCOMMAND__MENUITEMCLICK, line 1616 of menuintf.pas $001FA534 TMENUITEM__CLICK, line 75 of ./include/menuitem.inc $001FAD6C TMENUITEM__DOCLICKED, line 269 of ./include/menuitem.inc $00034898 TOBJECT__DISPATCH, line 465 of
/usr/local/src/fpc/fpcbuild-2.4.0/fpcsrc/rtl/inc/objpas.inc $002D915C DELIVERMESSAGE, line 112 of lclmessageglue.pas $002A8944 DELIVERMESSAGE, line 3516 of gtk2proc.inc $0033FDD0 GTK2MENUITEMACTIVATE, line 138 of gtk2wsmenus.pp WARNING: TLCLComponent.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event?
[TMainIDE.Destroy] A
[TMainIDE.Destroy] B -> inherited Destroy... TMainIDE [TMainIDE.Destroy] END

I've not tried building a significant project yet. As noted before this is on a unit with extremely limited RAM, it's using swap heavily so there's scope for race conditions etc.

I find that I only get symbols on the backtrace (sent by Lazarus to stdout) if run in the directory with the lazarus binary (/usr/local/share/lazarus-trunk), I've not tried using gdb.

Any comments would be appreciated, otherwise I'll try a "make bigide" at the end of the day.

"make bigide" is OK on Debian armel, but I still get an exception on entry or when opening a project similar to the above. lazbuild is OK.

PPC (Power Mac G3) on Debian "Lenny"
------------------------------------

make bigide completed without significant problems.

A minor problem I came across is that if the lazarus source directory is moved intact between development systems of different architectures the tools/svn2revisioninc binary isn't deleted by a make clean. I was going to report this as a bug but am still hunting for my user ID and password.

SPARC on Debian "Lenny"
-----------------------

I initially tried 2.5.1 for this because of a problem in 2.4.0. That didn't work due to

Compiling eventcodetool.pas
Compiling extractproctool.pas
Assembling extractproctool
eventcodetool.pas(124,9) Fatal: Syntax error, ")" expected but "," found Fatal: Compilation aborted

Looking at the source I see

const
   MethodKindAsString: array[TMethodKind] of shortstring = (
         'procedure', 'function', 'constructor', 'destructor',
         'class procedure', 'class function'
         {$IFNDEF VER2_4}
         ,'class constructor', 'class destructor'
         {$ENDIF}
       );

Reverting (?) to 2.4.2-RC1 compiles (make bigide) and executes OK, but when loading an existing project or exiting from the IDE I get

$ lazarus
TMainIDE.ParseCmdLineOptions:
PrimaryConfigPath="/home/markMLl/.lazarus"
SecondaryConfigPath="/etc/lazarus"
NOTE: miscellaneous options file not found - using defaults TMainIDE.DoNewProject A
TApplication.HandleException Access violation
Stack trace:
$000000CB
WARNING: TLCLComponent.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event?
[TMainIDE.Destroy] A
[TMainIDE.Destroy] B -> inherited Destroy... TMainIDE [TMainIDE.Destroy] END
$

These are the same two cases that give 0.9.29 + 2.4.0 problems on armel.

As with armel, lazbuild is OK.