[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fpc build problems on some debian armel buildds



Hector Oron wrote:
Hi,

2011/7/1 Hector Oron <hector.oron@gmail.com>:

I'll upload this
binaries at this time unless you state the contrary.

Instead of this, I have given back (trigger a rebuild) the package, as
it was only built once at the end of may.
The retry failed
Second, if the error reproduces again try to add more diagnostics code
around the test, check alignment, environment, trace it, etc...
It appears to be triggered by the length of the path to the build directory, I've managed to get it to happen under strace but only by inserting the strace command into the makefile (manually re-running the failling command after the failure succeeds) and the trace did not reveal anything out of the ordinary.

read(3, "\n{$ifdef has_signal}\nVar\n  NewSi"..., 32768) = 605
fstat64(3, {st_mode=S_IFREG|0644, st_size=1999, ...}) = 0
_llseek(3, 0, [1999], SEEK_CUR)         = 0
close(3)                                = 0
this was followed by a load of munmaps (which were presumablly the stack being unwound and memory freed up) which was followed by the error

From speaking to the upstream developers it looks like it may be a manifestation of a syscall related bug that has been fixed in current trunk (i'm currently speaking to upstream about the backportability of said fix) which causes syscall results to somtimes come out wrong and it seems the precise conditions of a build in a directory path of the length used by the buildds with the environment variables set by dpkg-buildpackage triggers it.

http://lists.debian.org/debian-arm/2011/06/msg00104.html



Third, attempt a build on a porterbox (abel or agricola), if the build
fails on buildd, but builds on porterbox manually 100% of the time, it
can probably be uploaded to the archive. But we should keep chasing
the problem.
Note that the failure is happening in the old compiler that is used to start the build process (freepascal is compiled with freepascal) not in the new compiler that is being built so even if a fix is uploaded to the archive a manual build may still be required.

I'd say It makes sense to upload a manual build to the archive. We want to keep the version in the archive reasonablly current because if it gets too old that can cause difficulties of it's own upgrading to the latest version (building freepascal is only officially supported with either the current version or one version prior to current).
Best regards,


Reply to: