Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

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.