[fpc-pascal] Cross compiling Windows to arm-linux

[Michael Schnell]

On 07/22/2013 09:52 PM, John Hansen wrote:
> I am working on an API library for the new LEGO MINDSTORMS EV3 programmable brick.  The brick is running Linux on a TI AM1808 ARM chip.
Does the EV3 provide any graphic ? If not, you will need to set up a 
remote debugging environment, best using Lazarus. In theory this should 
be possible in two ways:
  - using gdbserver on the target and a "cross gdb" on the PC, the two 
connected via the gdb-propriety protocol (here stopping a running 
project from the PC other than on a breakpoint is not possible ) ,   or
  - using standard ARM gdb on the target and access same from Lazarus 
using SSH (no such limitations, but Lazarus does not provide this "out 
of the box" (AFAIR, the appropriate code is not decently tested and 
commented out).

AFAIK neither way has been set up successfully yet.

A friend of mine and myself tried to do this for our ARM based NAS 
devices by QNAP, but while we did not give up at the moment the project 
is stalled

If the EV3 is powerful enough to run a VNC server, same can be used an X 
Server for a GUI interface and that way you might be able to run the 
Lazarus IDE native on the device to do comfortable debugging.

> I tried to run a binary for the first time that used TThread and I got a run-time error message that, via Google, told me I needed to use cthreads as the first unit in my program source code.  After adding that to my uses statement I now get linker errors.
>
> lcd_test.dpr: warning: 31: "crti.o" not found, this will probably cause a linking failure ...

I ran into a similar problem, doing native compiling on the ARM, trying 
to compile a project that includes Synapse. I found that  the "crt" 
stuff is necessary for attaching to dynamic libraries (.so files in 
Linux). It is linked in, when the project might _possibly_ intend to 
attach to a dynamic library.

I was able to link the project by providing some (AFAIR *.so) files and 
set the linker path appropriately.


If you in fact want to use TThread, there are some additional 
considerations:

The normal "Lazarus" programming way is to have a MainThread and Worker 
threads. The main thread in "normal" Lazarus applications is based on an 
event queue, so that the application programmer can do "event driven 
programming" and does not have to bother about a "main loop". The worker 
threads can notify the main thread by pushing events into the queue.

Unfortunately, in Lazarus, none of the multiple "LCL Widget Type"s is 
able to _not_ attach to a GUI API of the system it runs on, while 
providing the said event queue. (Of course when using a GUI, events 
generated by TThread instances are merged with events generated by the 
GUI. )

So you you are on your own when using threads on non-GUI enabled systems.

-Michael