So far this hasn't been considered a bug (hey, it is after all pretty normal for p2p GUIs to need 512 MB of RAM, now isn't it? ;>) but I think it definitely should be. This crazy 512 MBs can be easily reduced to a much lower amount of memory by splitting interface.c into a few smaller files. I have created two Perl scripts that can do it - both attached to this bug entry. And here is the additional code for dc-gui ebuild (just put it where appropriate): cp ${FILESDIR}/split_interface_fast.pl ${S}/src cd ${S}/src ./split_interface_fast.pl cd ${S} I have tested this with 0.74 and 0.75 and had no problems with it.
Created attachment 17272 [details] interface.c splitter for dc-gui This version preserves local variables and is pretty slow.
Created attachment 17273 [details] interface.c splitter for dc-gui (faster) This is a hell lof faster than the previous version but it does make some local variables global. It's ok because it doesn't break anything but in case people don't like the idea - there is always the first version of the script..
do you have a swap partition active ?
Yes, I do. Without a swap partition it doesn't compile at all (I have 256 MB RAM).
imvho if a program uses more than 50 megs of ram to compile something is _very_ wrong
interface.c is wrong - it's a big, GLADE-generated file. That's why I wrote the script to split the biggest function in interface.c into smaller parts, so that gcc doesn't need 512 MB of memory to compile this.
added to cvs, thanks for the leet script ;)
