From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Ru6GZ-0003tN-A8 for garchives@archives.gentoo.org; Sun, 05 Feb 2012 17:52:43 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0C197E0832; Sun, 5 Feb 2012 17:52:24 +0000 (UTC) Received: from mail.klenot.cz (mail.klenot.cz [87.236.199.95]) by pigeon.gentoo.org (Postfix) with ESMTP id AB563E07E8 for ; Sun, 5 Feb 2012 17:48:50 +0000 (UTC) Received: from localhost (amavis1.klenot.eu [10.10.10.187]) by mail.klenot.cz (Postfix) with ESMTP id A39174B2AE for ; Sun, 5 Feb 2012 18:48:49 +0100 (CET) X-Virus-Scanned: by amavis at klenot.cz Received: from mail.klenot.cz ([10.10.10.50]) by localhost (amavis1.klenot.eu [10.10.10.187]) (amavisd-new, port 10024) with ESMTP id hBz5VeSzFWEl; Sun, 5 Feb 2012 18:48:47 +0100 (CET) Received: from [10.111.111.222] (83-114-80-78.tmcz.cz [78.80.114.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.klenot.cz (Postfix) with ESMTP id DEBBB4B274; Sun, 5 Feb 2012 18:48:45 +0100 (CET) Message-ID: <4F2EC0FA.2070801@volny.cz> Date: Sun, 05 Feb 2012 18:48:42 +0100 From: Samuraiii User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120116 Thunderbird/9.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: [gentoo-user] =?UTF-8?B?wqstwrs6IFtnZW50b28tdXNlcl0gZGlzdGNjIC0gYW1kNjQgYW5kIHg=?= =?UTF-8?B?ODY=?= References: <4F2EB69A.2030205@volny.cz> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: id=80C752EA; url=http://pgp.mit.edu:11371/pks/lookup?search=0x80C752EA&op=vindex&fingerprint=on&exact=on X-TagToolbar-Keys: D20120205184842510 Content-Type: multipart/alternative; boundary="------------080705070604060202070400" X-Archives-Salt: 9664192c-5d47-4886-a823-515fdd61b583 X-Archives-Hash: 662afac6e937c21cea5ba180fdb33f0e This is a multi-part message in MIME format. --------------080705070604060202070400 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2012-02-05 18:38, Michael Mol wrote: > On Sun, Feb 5, 2012 at 12:04 PM, Samuraiii wrote: >> Hello, >> >> I have (right now) 3 computers runing Gentoo and as two of them are with >> only 1GB of ram - which for libreoffice compiling is not enough. >> >> So my questions are: >> >> 1) Is it possible with distcc overcome this memory limitation? -call compile >> on "weak" machine and leave memory load on "strong" one > To a limited extent, yes. You could configure things such that > compiles happen remotely, but links always have to happen locally. And > anything not done with a C or C++ compiler happens locally. > > AFAICT, any C or C++ app's most memory-consumptive act is linking. > > Your better bet is probably going to be to add swap. The swap thing is good idea but wont work because (libreoffice is one of examples) ebuild checks for available ram not swap so when there is eg. 962MB of ram it fails right in begining of merge I myself have really huge (4GB+) swap for some reasons -- Samuraiii e-mail: samuraiii@volny.cz GnuPG key ID: 0x80C752EA (obtainable on http://pgp.mit.edu) Full copy of public timestamp block signatures id- (from ) is included in header of html. --------------080705070604060202070400 Content-Type: multipart/related; boundary="------------010009000005060901040308" --------------010009000005060901040308 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit



On 2012-02-05 18:38, Michael Mol wrote: 
On Sun, Feb 5, 2012 at 12:04 PM, Samuraiii <samuraiii@volny.cz> wrote:

Hello,

I have (right now) 3 computers runing Gentoo and as two of them are with
only 1GB of ram - which for libreoffice compiling is not enough.

So my questions are:

1) Is it possible with distcc overcome this memory limitation? -call compile
on "weak" machine and leave memory load on "strong" one

To a limited extent, yes. You could configure things such that
compiles happen remotely, but links always have to happen locally. And
anything not done with a C or C++ compiler happens locally.

AFAICT, any C or C++ app's most memory-consumptive act is linking.

Your better bet is probably going to be to add swap.
The swap thing is good idea but wont work because (libreoffice is one of examples) ebuild checks for available ram not swap so when there is eg. 962MB of ram it fails right in begining of merge

I myself have really huge (4GB+) swap for some reasons
--
Samuraiii
e-mail: samuraiii@volny.cz
GnuPG key ID: 0x80C752EA (obtainable on http://pgp.mit.edu)
Full copy of public timestamp block signatures id- (from ) is included in header of html.
--------------010009000005060901040308 Content-Type: image/gif; name="bg-linky.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="bg-linky.gif" R0lGODlhAQAmAJEAAOzs7P///wAAAAAAACwAAAAAAQAmAAAIEAADCAwAAMDAgwgRFkzIMCAA Ow== --------------010009000005060901040308-- --------------080705070604060202070400--