https://sourceware.org/bugzilla/show_bug.cgi?id=22831
--- Comment #19 from Luke Kenneth Casson Leighton <lkcl at lkcl dot net> --- (In reply to H.J. Lu from comment #18) > (In reply to Luke Kenneth Casson Leighton from comment #17) > > https://issues.guix.info/issue/33676 > > > > so we have a successful report that the advised option helps. > > > > Have you tried my users/hjl/pr18028 branch? as i mentioned before, i (personally) do not have the resources to try anything out: i am acting as a go-between, to find people who *can* try out different branches. i took a look at the diffs: https://github.com/hjl-tools/binutils-gdb/compare/users/hjl/pr18028#diff-e65a96fc956244cba3a031705b7b737aR3484 some comments: bfd/linker.c line 3492 - i see what's going on. this is great, it *in principle* makes sure that the amount of memory used is not exceeded. bfd/linker.c line 3484 - this is completely arbitrary. this is NOT repeat NOT, as i have already said, and repeat, NOT limited to 32 bit. 64-bit systems ALSO HAVE THE EXACT SAME PROBLEM. this test needs to be removed. ld/ldmain.c: line 275 - specifying half the memory is arbitrary. so, as i said: it is not enough. what if the amount of memory used by other programs exceeeds half the available memory? conditions where that will occur immediately: make -j2. one ld process will take half the memory the other ld process will take half the memory. now BOTH processes will enter thrashing. as i said, right in the original report: it is necessary to DYNAMICALLY check the amount of available memory, just like gcc does. in that way, ld will remain DYNAMICALLY under the limit, it will STAY in resident memory. ld must be prevented from going into swap space, at all costs, basically. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils