From owner-freebsd-ports@FreeBSD.ORG Thu Mar 16 19:58:14 2006 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5026816A41F for ; Thu, 16 Mar 2006 19:58:14 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from vexpert.dbai.tuwien.ac.at (vexpert.dbai.tuwien.ac.at [128.131.111.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D887C43D45 for ; Thu, 16 Mar 2006 19:58:13 +0000 (GMT) (envelope-from gerald@pfeifer.com) Received: from acrux.dbai.tuwien.ac.at (acrux [128.131.111.60]) by vexpert.dbai.tuwien.ac.at (Postfix) with ESMTP id 66D1D137B9; Thu, 16 Mar 2006 20:58:12 +0100 (CET) Date: Thu, 16 Mar 2006 20:58:17 +0100 (CET) From: Gerald Pfeifer To: "[LoN]Kamikaze" In-Reply-To: <4418A188.8060200@gmx.de> Message-ID: References: <4418A188.8060200@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ports@freebsd.org Subject: Re: lang/gcc41 - libjava X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2006 19:58:14 -0000 On Thu, 16 Mar 2006, [LoN]Kamikaze wrote: > Today I removed the lines > # FIXME: As of 20051202, installing libgcj nearly kills 1GB machines. > WITHOUT_JAVA= yes > > from the ports Makefile. The previous version of the Port gave me > "virtual memory exhausted" messages, even with 800MB of free memory > available. However this time a > > # make makesum build > > Ran through without troubles. > > A "make install" gave me the message again, but forcing an installation > with "make -i install" seems to work. I only compiled a small "Hello > World!", but that is better than nothing, I guess. Thanks for this input! The problem I see is that "make -i" will not only ignore out-of-memory conditions but *any* errors occuring. Given that we generally test updates before releasing to our users we might get away with that, but these builds will not be reproducible: depending on the memory in her build machine, a user will get different results, some of which may match your positive experience, some of which may not. As an alternate approach, Maho-san and me are currently discussing to use the new gmake-devel port which has fixes to address the situation on the gmake side for the time being. Gerald