From owner-freebsd-toolchain@freebsd.org Wed Apr 5 17:02:13 2017 Return-Path: Delivered-To: freebsd-toolchain@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 9B4EDD30826; Wed, 5 Apr 2017 17:02:13 +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 5C8E0661; Wed, 5 Apr 2017 17:02:13 +0000 (UTC) (envelope-from rezny@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1406) id 79DB8469C; Wed, 5 Apr 2017 17:02:12 +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: Wed, 05 Apr 2017 19:01:35 +0200 Message-ID: <2629274.jcOtFEnjsX@workstation.reztek> Organization: FreeBSD User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20170405161541.GA32323@FreeBSD.org> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <2502554.oHoOYGyFJH@workstation.reztek> <20170405161541.GA32323@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 17:02:13 -0000 On Wednesday 05 April 2017 16:15:41 Alexey Dokuchaev wrote: > On Thu, Mar 30, 2017 at 07:26:43PM +0200, Matthew Rezny wrote: > > 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{35,36,37} are statically linked and thus smaller than normal. llvm38 > > switched to dynamic linking, the default, thus the size grew. > > Hmm, I don't quite get it: shouldn't static linking actually increase the > binaries (and thus the package) size? > I might have reversed static and shared somewhere in the linking explanation, or not properly described the situation. Versions prior to 3.8 could either build libLLVM as a static library and link all the LLVM binaries to that (recommended), or build it as a shared library and link the LLVM binaries to that (recommended for development only, but Mesa needs libLLVM.so). LLVM 3.8 introduced the 3rd option, build the shared library for external use, i.e. Mesa, but link the LLVM binaries to the libLLVM*.a bits that were used to build the shared library. llvm37 was built the non-recommended way for the benefit of Mesa, the LLVM binaries were linked to the shared library that Mesa used. llvm38 turned building/linking of the shared library, so there would be some increase since each LLVM binary now had that portion static linked. llvm39 turned on building of the shared library but did not enable linking with it so the LLVM binaries remain linking that part static, meaning the package grows by the size the shared library that is installed but not used by LLVM itself. Those were changes to a portion, not a complete change between static and shared linking for the whole package, so I was somewhat surprised by the size difference you noted, but of course I had forgotten that all the parts were collapsed into the llvm port. There was a brief period in which llvm39 was fully switched to dynamic linking, which made it considerably smaller but caused runtime problems (and was also likely to be slower). > > I assume llvm40 will be a bit bigger, but do not expect to see another > > jump as you've observed. > > As Mark Millard reports: > > I've also tried without WITH_DEBUG= and now. . . > > > > # pkg delete llvm40 > > Checking integrity... done (0 conflicting) > > Deinstallation has been requested for the following 1 packages (of 0 > > packages in the universe): > > > > Installed packages to be REMOVED: > > llvm40-4.0.0 > > > > Number of packages to be removed: 1 > > > > The operation will free 1 GiB. > > That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. > I'm surely looking forward modularization of LLVM port; rebuilding it > every time becomes a real PITA given that X11 stack requires it. :-( > > ./danfe I have both llvm39 and llvm40 installed here (amd64) with all options enabled and without any WITH_DEBUG. According to pkg, the flat (installed) size of llvm39 is 1.10GB and llvm40 is 1.31GB, so not a huge difference (<20%) but still steady growth. The best solution to cut rebuild time for LLVM is ccache.