From owner-freebsd-ppc@freebsd.org Thu Mar 30 17:26:44 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E172DD2685E; Thu, 30 Mar 2017 17:26:44 +0000 (UTC) (envelope-from rezny@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BCB9A773; Thu, 30 Mar 2017 17:26:44 +0000 (UTC) (envelope-from rezny@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1406) id 14ED14A61; Thu, 30 Mar 2017 17:26:44 +0000 (UTC) From: Matthew Rezny To: Alexey Dokuchaev Cc: Dimitry Andric , Mark Millard , Johannes M Dieterich , FreeBSD Current , FreeBSD Toolchain , FreeBSD Ports , FreeBSD PowerPC ML Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Date: Thu, 30 Mar 2017 19:26:43 +0200 Message-ID: <2502554.oHoOYGyFJH@workstation.reztek> Organization: FreeBSD User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20170330170648.GA38004@FreeBSD.org> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 17:26:45 -0000 On Thursday 30 March 2017 17:06:48 Alexey Dokuchaev wrote: > On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote: > > On 26 Mar 2017, at 23:36, Mark Millard wrote: > > > ... > > > Also interesting was: > > > > > > Installed packages to be REMOVED: > > > llvm40-4.0.0.r4 > > > > > > Number of packages to be removed: 1 > > > > > > The operation will free 49 GiB. > > > > Yes, this is big. But there is no real need to build the llvm ports > > with debug information, unless you want to hack on llvm itself. > > Cc'ing jmd@ and rezny@. > > I've been watching increasing size of our LLVM packages with increasing > worry. This is from my tinderbox cache: > > $ % env LANG=C ls -lh llvm3* > -rw-r--r-- 1 root wheel 17M Jan 29 2016 llvm35-3.5.2_1.txz > -rw-r--r-- 1 root wheel 18M Mar 7 2016 llvm36-3.6.2_2.txz > -rw-r--r-- 1 root wheel 27M Feb 28 01:05 llvm37-3.7.1_4.txz > -rw-r--r-- 1 root wheel 207M Jan 19 18:20 llvm38-3.8.1_5.txz > -rw-r--r-- 1 root wheel 244M Mar 23 16:42 llvm39-3.9.1_2.txz > > Dimitry, do you know what had causes such a huge bump in 37 -> 38? > > They take lots of time to build and package. And given that llvm > is indirect dependency of any X11-related port, it pessimises their > build times as well (devel/libclc now requires devel/llvm40 after > r437268). > > With 49 GiB llvm40, I guess I won't be able to build-test post as my > hardware would just not be capable enough. > > ./danfe LLVM 3.8 introduced the option to build a shared LLVM library, which is what Mesa needs for use at runtime (for e.g. compiling shaders), separate from linking to it. Previous versions only had one option, if the library was built then all the LLVM binaries were staticly linked to it. LLVM devs state that static linking the LLVM binaries is only for developer use, users should not do that. Mesa's need was causing distributions to ship static linked LLVM binaries against that advice. So, they added a pair of switches so that we can separately control whether that library is built (required for Mesa) and used to link LLVM binaries (not desired). llvm{35,36,37} are statically linked and thus smaller than normal. llvm38 switched to dynamic linking, the default, thus the size grew. llvm39 added the library Mesa needs (we didn't turn on the option in llvm38 since Mesa jumped from 37 to 39), so it grew a little more. I assume llvm40 will be a bit bigger, but do not expect to see another jump as you've observed.