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

[Mark Morgan Lloyd]

Ludo Brands wrote:
>> 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. 

Yes, but that VNC is in the IP space of the host, and having multiple 
sessions (e.g. multiple guests of different types, or multiple sessions 
from a single guest) gets messy. I tend to use it only if the guest is 
Windows, although on one version of Qemu I've got here it occasionally 
screws the (Windows guest) mouse pointer necessitating a reboot.

>> 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. 

Again, running a guest (rather than host) Qemu should allow you to 
specify the size, since it doesn't refer to the emulated hardware or 
(the equivalent of) a BIOS or OBP. I run 16-bits as standard, I've not 
checked whether that's what I actually get but visually I see no obvious 
problems.

>> 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.

256M? Luxury! I'm not saying that this is a sensible thing to attempt, 
but Lazarus will just about run in FluxBox on a 32Mb "Slug".

>> 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. 

In that case it must have been fixed. You'd have noticed :-)

> 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. 

Thanks, I'll get it presently.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]