[fpc-devel] Re: fpc build problems on some debian armel buildds
plugwash at p10link.net
Thu Jun 30 19:04:52 CEST 2011
Mark Morgan Lloyd wrote:
> Riku Voipio wrote:
>> On Thu, Jun 30, 2011 at 03:33:36PM +0100, peter green wrote:
>>> The current FPC package builds fine in qemu for me. I will attempt
>>> to try on some real hardware too when I get a chance.
>> Qemu allows unaligned memory accesses, which do not always work on real
>> hardware, especially on armv5 and other older arms.
>>> Is there a list anywhere of what hardware the buildds run on and/or
>>> any other interesting information about their setups so I can try
>>> to figure out what if anything the failing buildds have in common.
>>> Has anything changed in ancina's configuration recently?
>> All currently running armel buildd's are identical marvell mv78x00
>> boards. Updates on ancina are the regular "apt-get upgrades" to get
>> latest toolchain
>> etc in sid.
> There were issues with some versions of FPC, related to more than a
> certain number of parameters (four?) being passed. Jonas wrote the
> following on the 5th October last year:
Do you know if that fix has made it into any stable releases and if so
> On 05 Oct 2010, at 10:05, Mark Morgan Lloyd wrote:
> > When running 2.4.0 on an ARM system (Debian v5 "Lenny", armel) with
> > limited memory (32Mb RAM + 768Mb swap) and using it to compile a large
> > project (Lazarus 0.9.28.2) I'm seeing intermittent failures which go
> > away if the make is restarted. I've not seen this running on other
> > platforms, and I don't believe it is a problem in the Lazarus sources
> > since the build will eventually complete giving me runnable code.
> A couple of days ago I fixed an error in svn trunk for ARMEL that
> caused the stack to become temporarily unbalanced after performing
> syscalls with 5 or more parameters (the bug is still there for OABI,
> but I can't fix that because I don't have access to an OABI machine).
> A side-effect of that bug was that if the caller passed the address of
> its own result as one of the parameters to the system call, it would
> afterwards return a random value as its result and checks for error
> results caused random failures like the one you posted (the
> reproducible case that allowed me to fix it was a similar error).
> There might be alignment issues on ARM and SPARC but I've only seen
> those with Lazarus, not with FPC itself.
More information about the fpc-devel