reassign 485596 ghc6 thanks Thiemo Seufer wrote: > FYI, it used to build before (probably because earlier gcc versions > used less RAM). This failure prevents migration of the package to > testing.
OK, that is interesting. AFAIK there has been no significant change upstream to WashNGO. I will therefore reassign this to ghc6 and see what Ian has to say. It is not practical to modify the source code to split up modules because doing so would break the API and compatibility with programs that use WASH. So if this is to happen, it will have to come from upstream. -- John > >> Thiemo Seufer wrote: >>> WASH/HTML/HTMLPrelude98.hs >>> WASH/HTML/HTMLMonad98.hs >>> WASH/HTML/HTMLPrelude.hs >>> >>> Compiling those eventually (after more than 30 minutes) results in .hc >>> files of about 30 MB (!). Then gcc-4.3 is invoked which some minutes >>> later gets killed when it comes close to the maximum process size. >> This sounds like you have a very slow machine. It does take some time >> to build on modern hardware (a few minutes), though I suppose the >> unregisterized bit could account for the difference. > > I tested on a 900 MHz Quadcore with 2GB RAM, running mips/unstable, > without artificial process size restrictions. > >> What is your maximum process size? > > 2GB is the architectural limit for 32-bit MIPS. AFAIK ARM and the 32-bit > variants of PPC, SPARC, s390 have the same limit. > >> I am aware that building washngo can >> use a considerable amount of RAM (probably even more on an >> unregisterized platform), but it is not a bug in washngo that you don't >> have enough RAM to build it, or that your maximum process size is too low. > > It is a bug in washngo or ghc6 or gcc when a generated C source file > causes the compiler to require excessive amounts of RAM (and build > time, causing timeouts on buildds). Currently it looks like a bug in > washngo to me, since it is AFAIK the only haskell progam in the archive > with that problem. > > Btw, I remember we had similiar problems with autogenerated C files for > python and SWIG interface wrappers. Those were solved by splitting the > generated C file. > >> ISTR it takes the better part of 1GB to build on i386. > > The i386 limit is 3GB on a standard kernel, so it would hit later anyway. > >> What specific platforms are you having problems with? It would be >> interesting to see if the buildds are having trouble there as well. I >> see it has built on alpha, amd64, hppa, ia64, i386, and sparc, > > With the exception of hppa those are 64-bit platforms or 32-bit > platforms with a registerized ghc6. I don't know what the process > size limit on 32-bit hppa is. > >> and most >> of the rest of the platforms show it as building (but haven't attepted >> recently due to missing build-deps) > > arm, armel, mips, s390 fail due to address space exhaustion. mipsel and > powerpc had missing build-deps, I predict that mipsel will fail the > same way as mips does, while powerpc has a chance to succeed since it > runs a registerized ghc6. > > > Thiemo > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
