On 30 Mar 2017, at 19:55, Brooks Davis <[email protected]> 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
+STRIP=
+.endif
+
_CRTLIBDIR=
${LLVM_PREFIX:S|${PREFIX}/||}/lib/clang/${LLVM_RELEASE}/lib/freebsd
.if ${ARCH} == "amd64"
_COMPILER_RT_LIBS= \
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...
-Dimitry
signature.asc
Description: Message signed with OpenPGP
