(debian-mips: please keep me and the bug in Cc if replying.)
On Wed, 28 Jan 2015 at 08:00:53 +0100, roucaries bastien wrote:
> Smell like an openmp bug.... ny memory they are a enviroment variable to
> disable openmp.
I tried building with --disable-openmp on a mips porterbox
(minkus.debian.org, which I believe is a dual Cavium Octeon II with no FPU,
the same as the buildds where imagemagick has been failing).
Unfortunately building with --disable-openmp doesn't seem to help.
On Thu, 29 Jan 2015 at 19:59:45 +0100, Bastien ROUCARIES wrote:
> try to add to convert command line "-limit thread 1"
Sadly that doesn't seem to help either.
> On Fri, Jan 30, 2015 at 2:37 PM, Dejan Latinovic
> <dejan.latino...@imgtec.com> wrote:
> > did anyone tried to wait some longer time to see if command will execute?
>
> No, but the build machines wait for a pretty long time before
> killing (5 hours), and I've checked that it uses the proc at 200%. We
> can't burden the build machines like that...
The latest experimental build (which adds some "echo", to stop sbuild
killing the build process after 5 hours of apparent inactivity) took
19 hours. That's longer than gcc-5 took on the same hardware.
While doing test builds yesterday evening, I was able to compile
imagemagick more than once, so it can't have taken longer than 2 or 3 hours;
assuming the porterbox and the buildd have a similar spec, that means
converting a SVG to a PNG 14 times is taking at least 16 hours.
That seems unusably slow to me. It's entirely possible that imagemagick
built for mips is currently only really useful on mips hardware that has
a FPU. Unfortunately, the mips buildds don't seem to have FPUs.
mips porters: how common are FPUs expected to be among mips machines
where Debian will run? Also, is it an ABI break for a mips library to
be built with -msoft-float? If mips FPUs are rare, and -msoft-float
produces a compatible ABI, then perhaps we should be compiling imagemagick
with -msoft-float, so it will use libgcc for somewhat slow floating
point emulation (like armel does), rather than very slow kernel traps
(like the old arm port)?
If -msoft-float is not viable, either because FPUs are common or because
it produces a different ABI, then it seems to me as though we need
some sort of compromise to make imagemagick builds complete in a finite time.
Bastien doesn't want to remove the smoke-test of the built binaries,
which I can understand; but at the same time, building imagemagick
shouldn't take 19 hours.
Bastien: perhaps the conversion of SVG to 14 PNG icons could move to the
arch-indep part of the build, and the smoke-test could be something
simpler, like a single image-resize operation? Even if that takes an
hour (leading to maybe a 3-4 hour total build time), that's way better
than spending 16 hours on a smoke-test.
> I could try building with another version of gcc, though.
Unfortunately, this has ceased to be an option, because g++-4.x and g++-5
produce a different ABI for libmagick++.
S
