On Sat, Aug 15, 2015 at 3:08 PM, Simon McVittie <[email protected]> wrote: > (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 >> <[email protected]> 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)?
I could add moreover a special lib for mips if you support subarch path like /lib/i686/cmov under i686 (partial arch will really help here but I could special case mips). > 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. Yes but I do not want to do that before next version. My priority is the new c++ library. Bastien >> 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
