The linker needs more memory if binutils is configured with --enable-64-bit-bfd option. Avoiding --enable-64-bit-bfd for binutils might be a better choice for native compilation on some embedded 32-bit platforms such as ARM. Reproducible: Always Steps to Reproduce: 1. Take some ARM device (1.4GHz quad Cortex-A9 with 1GB of RAM in my case, swap on SD card) 2. Disable swap 3. Try to emerge www-client/firefox-15.0.1 and wait until it finishes compiling and runs out of memory on the linking step 4. Enable swap and re-run the failed link command, measure time and watch swap usage: real 12m14.108s user 1m15.655s sys 0m25.470s Swap usage peaks at ~1310MB. Hence the total memory usage is ~2.3GB (1GB RAM + ~1.3GB swap) 5. Edit /usr/portage/eclass/toolchain-binutils.eclass and remove the line which enforces --enable-64-bit-bfd option, emerge binutils 6. Run the same mozilla link command again, measure time and watch swap usage: real 8m27.364s user 1m12.890s sys 0m19.815s Swap usage peaks at ~760MB. Hence the total memory usage is ~1.8GB (1GB RAM + ~0.8GB swap). Looks like quite a measurable improvement. Memory footprint goes down by nearly 30%. It might be even possible to successfully emerge firefox with 2GB VMSPLIT kernel configuration.
was first introduced here: http://sources.gentoo.org/sys-devel/binutils/binutils-2.11.92.0.12.3-r1.ebuild unfortunately, there's no changelog and the commit message is useless, and there's no reference as to why the flag was added. we can probably restrict the flag so it only gets passed with USE=multitarget. i'll have to noodle on it, but i can't think of reasons off the top of my head as to why not enabling this for 32bit hosts/targets would be a problem.
http://sources.gentoo.org/eclass/toolchain-binutils.eclass?r1=1.118&r2=1.119
