On 30 Mar 2017, at 19:55, Brooks Davis <bro...@freebsd.org> wrote:
> On Thu, Mar 30, 2017 at 07:26:19PM +0200, Dimitry Andric wrote:
>> As said, this is because of WITH_DEBUG.  Don't use that for the llvm
>> ports, for now.  It will also allow you to build them with much less RAM
>> in the machine: especially linking can take multiple GB when debuginfo
>> is enabled, and optimization is off.
> I'm looking into improving WITH_DEBUG.

I stole the following method from graphics/darktable:

Index: devel/llvm40/Makefile
--- devel/llvm40/Makefile       (revision 436685)
+++ devel/llvm40/Makefile       (working copy)
@@ -236,6 +236,11 @@ NOT_FOR_ARCH=      ia64

 .include <bsd.port.pre.mk>

+.if defined(WITH_DEBUG)
+CMAKE_BUILD_TYPE=      RelWithDebInfo
 .if ${ARCH} == "amd64"

This appears to work for me.

> P.S. Somewhat off topice, but related.  FAIR WARNING: the days of
> self-hosted 32-bit systems are numbered.  Switching to lld from our
> ancient BFD linker will probably buy us some time, but I'd be surprised
> if you will be able to build LLVM+CLANG with a 2GB address space in 5
> years.  The sooner people make their peace with this, the better.

Yes, with that above RelWithDebInfo change, GNU ld tends to use ~5G of
memory to link the larger llvm executables, so that is definitely beyond
i386, even if you run it in a jail on an amd64 host.

And if you would want to use link time optimization, the requirements
will increase even more...


Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to