On Fri, Oct 11, 2013 at 09:55:34PM +0100, Dmitrijs Ledkovs wrote: > I'm not sure, but launchpad is running 64-bit machines even when > compiling for the i386 architecture, and then launchpad supports PAE > only and thus can get >4GB of address space.
A 32-bit process can still only address 32-bits of memory. PAE only lets you extend past 4GB across *multiple* processes; the 4GB limit still applies to any one 32-bit process. > I think debian buildds are also all 64-bit apart from one (or > something like that) thus it shouldn't be a problem there. > > Last time I spoke with Colin about yade FTBFS due to memory > exhaustion, the recommendation he gave was to reduce translation units > and thus to reduce the compiler memory usage. GCC memory usage can go > very large and has regressed since 3.3 when templates are used > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12850 > It has been done before for some other packages, but i haven't yet had > time to look more into yade. I think that's the best way to go for > yade, to address it in the source-code / restructure it to use less > memory at compile time. Yes, even if we can pinpoint a specific recent change in the compiler that caused increased memory usage, the most reliable fix for the problem is going to be to just refactor this code. If your compiler is taking anywhere near 3GB of memory to build a single object file, that's not a good thing anyway. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature