[LLVMdev] CMake pools for linking?
Renato Golin
renato.golin at linaro.org
Sun Nov 17 02:44:43 PST 2013
Are you building in Debug mode? Buildbots should build in Release+Asserts
mode.
Building LLVM in debug mode crashes even my quad-core i7 16GB RAM laptop,
no wonder an odroid. But that's LD's fault. If you use Gold, everything
works as expected.
Another alternative is using Ninja pools, but we'd need a CMake connection
to generate the Ninja files with the link pools, which I don't think it's
in production yet (there were some implementations on the development
trunk).
cheers,
--renato
On 16 November 2013 23:31, Mikael Lyngvig <mikael at lyngvig.org> wrote:
> Hi,
>
> I've noticed on both PCs and ARM boards that it is the linking process
> that "brings down" the system (makes it swap if it is not equipped with
> plenty of RAM). So I have been thinking if it would be possible to use the
> CMake pool feature to make the LLVM build system only issue one link
> command at a time - it seems a bit unfortunate that N simultaneous link
> commands are issued when you pretty much know beforehand that the system is
> only likely to be able to serve one link command, if that much, given its
> less-than-optimal-amount of memory.
>
> I just want to hear if this is something that anybody is willing to look
> into - and if it is something that should be looked into at all? I don't
> think I can figure this out on my own and I think it would be rather easy
> for somebody familiar with CMake.
>
> I notice that there are a lot of low-end machines on the builders list in
> Zorg, so I cannot be the only one who would experience this addition as
> great.
>
>
> Sincerely,
> Mikael Lyngvig
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131117/cb4338ed/attachment.html>
More information about the llvm-dev
mailing list