[Lazarus] RE : RE : RE : RE : RE :RE:RE:RE:FPC_REQUIRES_PROPER_ALIGNMENTdefinedonSolariscausescrashinlazarus

[Ludo Brands]

> 
> http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators 

Interesting. 
I found that the qcow format is slowing installation a lot. The filesystem
spends more time growing the qcow disk than anything else. The raw format is
faster. 

> 
> But in the case of SPARC-on-Qemu you should be able to use VNC 
> (specifically, Debian's vnc4server package), in conjunction 
> with FluxBox 
> as desktop/wm it's fairly lean and performs well. The machine 
> in front 
> of me is a (real) SPARC running Etch, thanks to your patches 
> 0.9.30+2.4.2 are now running fine on it so there's a fair chance the 
> same would apply to an emulated system; I'm in no great hurry 
> to update 
> this system to a later OS but am overdue for going round 
> everything and 
> getting onto 2.4.4.

QEMU comes now with an integrated VNC server. The problem is that the
OPENBIOS used for sparc supports only 8 bit or 24 bit color depths while the
debian suntcx driver doesn't support 24 bits. Leaves the 8 bit which lazarus
doesn't support. VNC doesn't change that. 


> 
> ARM is more of a problem since vnc4server is not ported to 
> it, I believe 
> that there are some ARM-specific problems in the VNC sources. 
> There's a 
> different server that does run on it (from memory, 
> tightvncserver) but 
> it appears to be hardcoded to expect the display manager to be xdm- I 
> prefer gdm since it's the only one with a reliable XDMCP 
> implementation.
> 

The QEMU build in VNC server for arm works well but gives you the small
resolution of the versatilepb board. 

> In either case you /should/ be able to connect to the system using 
> XDMCP, e.g. using Xnest on your local system and gdm+FluxBox on the 
> headless one, subject to your network setup since XDMCP is a 
> UDP-based 
> protocol which implies that broadcasts don't route well. 

On both arm and sparc I'm using XFCE which is quite lean also. I noticed
very little difference in speed when running lazarus with X transported over
ssh (no windowmanager running on the guest) or running in a windowmanager.
The cpu time spent in ssh/sshd transferring the X packets roughly equals the
cpu time spent by the window manager dealing with them. The advantage of ssh
is the increased resolution/color depth. For the arm limited to 256M memory,
not running a windowmanager gives you also more precious memory.


> However at one 
> time (I don't know whether this is fixed) Lazarus and some other apps 
> performed very badly using networked X, my recollection is that the 
> consensus was that there was excessive input-device polling.
> 

I noticed that the small hints that pop up when you hover over about
anything are very costly. The cause a lot of painting and repainting. 

I just uploaded another patch for syneditmiscclasses.pp. When you cut a text
in one unit and paste it in another unit a sigbus exception was thrown. A
char pointer cast to an integer pointer. 

Ludo