From owner-freebsd-toolchain@freebsd.org Sun Mar 26 12:07:45 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 040F3D124D4; Sun, 26 Mar 2017 12:07:45 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 759C81889; Sun, 26 Mar 2017 12:07:44 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id x137so9789158lff.3; Sun, 26 Mar 2017 05:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9s7jlmzSFGnGUr3N8L9/bw21b5uvSZN+LzZAWAH6dhs=; b=ZMrrArW1jJEnpWdazzXt/CbkdYUdj3WKR0Qbl7yuEx3z9/ZjsDiAK/gm5IUY7tJVm8 h6+BuqNqe24G0SMxGcgEyoe+yMY2Rh1ElOVMFsTqG+f4V13pMoeU3DLzgOlBdFJd6rme cSdDvCvFUM+G3UxFyFgTEiopWc1qIR1rbbJQnWObvoiXd45KVz7hnWaR2itX63bP+eY9 bmoBTaFC6v3tTZtclprYB+6itzw9epmDdIeL6F/6So3knS+Tl4Mo3FERZb4R7SI9rWh+ 4ZgSORLCyMFBOQuV1vWvp1kkGi4MYpdGB/3Nebket66+ZzM0EMIh3EsyQf4i8mjoN3FP sLUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9s7jlmzSFGnGUr3N8L9/bw21b5uvSZN+LzZAWAH6dhs=; b=J7JW3iQnMhugViv3X6RyHiFcxWlBWcqXWzfa+e75qEM872ZclydCqe3zDmqD9TbYsP lhnQ9A2w6jtkTNxS+wjh/iX8U4vvVHhjnaPjEP9dTIChlEhQSHmu7+Ca4UKAZBOTx6+n Wvvdkghvheq0tFjREKhXkjtdPEnIzEn7JbSnpYWegz93gfrl0sixXJSS6RGa4ORm4Lw0 dat2VMAoHtc4oJSdjKy8B9G1NPe3gGwerBYa9DBAGv456HhP2ng2xQwl05/yUVxvabgX wwe1s6a1kF4v9xtXlkCp82stt9VgDlfWumqs5LhDYKuBYN1WxPep2ypCj+GVUkUj/0n0 uPvQ== X-Gm-Message-State: AFeK/H1hcLciSb02PhihMGA+k3WdO2r+8nXfde8p/vQYzp1yLF51+QkAzE8J9yvKUWP49aFDAvwVUuYUinTu9g== X-Received: by 10.25.0.148 with SMTP id 142mr8639677lfa.156.1490530062398; Sun, 26 Mar 2017 05:07:42 -0700 (PDT) MIME-Version: 1.0 Sender: lwhsu.freebsd@gmail.com Received: by 10.25.193.22 with HTTP; Sun, 26 Mar 2017 05:07:41 -0700 (PDT) In-Reply-To: <906EDF27-C387-4188-978F-66B81E31093B@dsl-only.net> References: <906EDF27-C387-4188-978F-66B81E31093B@dsl-only.net> From: Li-Wen Hsu Date: Sun, 26 Mar 2017 20:07:41 +0800 X-Google-Sender-Auth: 9RLogrV68EaaaMonwE2kAmoors0 Message-ID: Subject: Re: I had to revert /usr/local/aarch64-freebsd from 2.28 for its bin/ld to work for -r315870 buildworld (adm64 -> arm64 cross build) To: Mark Millard Cc: Baptiste Daroussin , FreeBSD Toolchain , freebsd-arm , FreeBSD Ports Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Sun, 26 Mar 2017 12:07:45 -0000 On Fri, Mar 24, 2017 at 11:31 AM, Mark Millard wrote: > Building /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc/libc. > so.7.full > --- libc.so.7.full --- > building shared library libc.so.7 > /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x3b): > R_AARCH64_ABS64 used with TLS symbol udb > /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x58): > R_AARCH64_ABS64 used with TLS symbol uf > /usr/local/aarch64-freebsd/bin/ld: utxdb.pico(.debug_info+0x5a): > R_AARCH64_ABS64 used with TLS symbol futx_to_utx.ut > /usr/local/aarch64-freebsd/bin/ld: jemalloc_tsd.pico(.debug_info+0x3c): > R_AARCH64_ABS64 used with TLS symbol __je_tsd_tls > /usr/local/aarch64-freebsd/bin/ld: jemalloc_tsd.pico(.debug_info+0x146e): > R_AARCH64_ABS64 used with TLS symbol __je_tsd_initialized > /usr/local/aarch64-freebsd/bin/ld: cxa_thread_atexit_impl.pico(.debug_info+0x3b): > R_AARCH64_ABS64 used with TLS symbol dtors > /usr/local/aarch64-freebsd/bin/ld: xlocale.pico(.debug_info+0x403): > R_AARCH64_ABS64 used with TLS symbol __thread_locale > /usr/local/aarch64-freebsd/bin/ld: setrunelocale.pico(.debug_info+0x3c): > R_AARCH64_ABS64 used with TLS symbol _ThreadRuneLocale > cc: error: linker command failed with exit code 1 (use -v to see > invocation) > I also see this on our CI server: https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/ , this job began failing since aarch64-binutils upgraded to 2.28 on pkg.freebsd.org. Should we revert this change for now? Or the fix is being prepared? Best, Li-Wen -- Li-Wen Hsu https://lwhsu.org From owner-freebsd-toolchain@freebsd.org Sun Mar 26 21:36:41 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 F3947D1FDDB for ; Sun, 26 Mar 2017 21:36:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-177.reflexion.net [208.70.211.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B56341709 for ; Sun, 26 Mar 2017 21:36:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20651 invoked from network); 26 Mar 2017 21:37:27 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 Mar 2017 21:37:27 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Sun, 26 Mar 2017 17:36:33 -0400 (EDT) Received: (qmail 6701 invoked from network); 26 Mar 2017 21:36:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Mar 2017 21:36:33 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 44100EC770C; Sun, 26 Mar 2017 14:36:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> Date: Sun, 26 Mar 2017 14:36:31 -0700 Cc: FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> To: FreeBSD Ports , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3259) 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: Sun, 26 Mar 2017 21:36:41 -0000 [I add some what-it-take-for-an-upgrade information.] On 2017-Mar-12, at 6:53 PM, Mark Millard wrote: > Summary: RAM+(peak swap) was about 26 GiBytes. > Also: about 118 GiByte /usr/obj/. . ./llvm40/ area. > (2 processors, 2 cores each, all in use; > WITH_DEBUG=3D used) >=20 > The peak usage times were when the 4 cores were > each busy running ld at the same time. >=20 > [So far as I know FreeBSD does not report peak swap usage > "since boot". So I do not have a cross check on if I missed > seeing a higher peak then I report in the details below.] >=20 > What all this note spans as part of the build: >=20 > # more /var/db/ports/devel_llvm40/options > # This file is auto-generated by 'make config'. > # Options for llvm40-4.0.0.r4 > _OPTIONS_READ=3Dllvm40-4.0.0.r4 > _FILE_COMPLETE_OPTIONS_LIST=3DCLANG DOCS EXTRAS LIT LLD LLDB > OPTIONS_FILE_SET+=3DCLANG > OPTIONS_FILE_SET+=3DDOCS > OPTIONS_FILE_SET+=3DEXTRAS > OPTIONS_FILE_SET+=3DLIT > OPTIONS_FILE_SET+=3DLLD > OPTIONS_FILE_SET+=3DLLDB >=20 > The system clang 4.0 was used to do the build. A port > binutils was used (-B${LOCALBASE}/bin/ in CFLAGS, > CXXFLAGS, an CPPFLAGS). The kernel was non-debug generally > but buildworld buildkernel did not have MALLOC_PRODUCTION=3D . > The llvm40 build did have MALLOC_PRODUCTION=3D . >=20 > # uname -paKU > FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT r314687M powerpc = powerpc64 1200023 1200023 >=20 > Most of what I have access to for FreeBSD does not have a > big enough configuration to do a WITH_DEBUG=3D build of llvm40 > on a machine with 4 cores, all in use. >=20 > One type of environment that does is an old PowerMac G5 > so-called "Quad Core" that has 16 GiBytes of RAM, 17 GiBytes > of swap, and a 480 GiByte SSD (but extra over provisioned so > it appears even smaller for the file system+swap). >=20 > Watching with top the peak swap usage that I saw was > 56% of the 17 GiByte --so call it 10 GiBytes or so. >=20 > So something like 16 GiBytes RAM + 10 GiBytes swap > and so something like 26 GiByte total. >=20 > I used portmaster with -DK. Afterwards the /usr/obj/ > sub-area for llvm40 used totaled to a size of: >=20 > # du -sg /usr/obj/portswork/usr/ports/devel/llvm40 > 118 /usr/obj/portswork/usr/ports/devel/llvm40 >=20 > So around 118 GiBytes of disk space. >=20 > Showing the major space usage contributions: >=20 > # du -sg /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/* = /usr/obj/portswork/usr/ports/devel/llvm40/work/stage/usr/local/llvm40/* > . . . > 29 /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/bin > . . . > 29 /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/lib > . . . > 12 /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/tools > . . . > 26 = /usr/obj/portswork/usr/ports/devel/llvm40/work/stage/usr/local/llvm40/bin > . . . > 24 = /usr/obj/portswork/usr/ports/devel/llvm40/work/stage/usr/local/llvm40/lib > . . . >=20 >=20 >=20 > Side notes that are more system specific: >=20 > The timestamps on the script output file indicate that > the build took about 8 hours 24 minutes. >=20 > The powerpc64 system used was built with the system clang > 4.0 compiler and a port-based binutils. This is despite that > clang 4.0 produces code that has any thrown C++ exceptions > completely non-functional for powerpc64 (program crashes > via signals reporting problems). I upgraded from llvm40 r4 to final. An interesting result was its creation of a backup package for llvm40-4.0.0.r4: about 13 cpu-core-hours running pkg create (Remember: I've been building with WITH_DEBUG=3D ) Its single-threaded status stands out via elapsed time approximately matching. I'll note that it was somewhat under 6 elapsed hours for staging to have been populated (-j4 with 4 cores present helps for this part). (Of course these elapsed-time figures are rather system dependent, although the ratio might be more stable.) Also interesting was: Installed packages to be REMOVED: llvm40-4.0.0.r4 Number of packages to be removed: 1 The operation will free 49 GiB. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Mar 26 22:22:04 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 B055ED1DF6F for ; Sun, 26 Mar 2017 22:22:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-174.reflexion.net [208.70.211.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 624971E33 for ; Sun, 26 Mar 2017 22:22:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30989 invoked from network); 26 Mar 2017 22:21:57 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 26 Mar 2017 22:21:57 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Sun, 26 Mar 2017 18:21:57 -0400 (EDT) Received: (qmail 10776 invoked from network); 26 Mar 2017 22:21:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Mar 2017 22:21:57 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id D2154EC770C; Sun, 26 Mar 2017 15:21:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: I had to revert /usr/local/aarch64-freebsd from 2.28 for its bin/ld to work for -r315870 buildworld (adm64 -> arm64 cross build) From: Mark Millard In-Reply-To: Date: Sun, 26 Mar 2017 15:21:56 -0700 Cc: FreeBSD Toolchain , freebsd-arm , FreeBSD Ports Content-Transfer-Encoding: quoted-printable Message-Id: References: <906EDF27-C387-4188-978F-66B81E31093B@dsl-only.net> To: Li-Wen Hsu , Baptiste Daroussin X-Mailer: Apple Mail (2.3259) 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: Sun, 26 Mar 2017 22:22:04 -0000 On 2017-Mar-26, at 5:07 AM, Li-Wen Hsu wrote: On Fri, Mar 24, 2017 at 11:31 AM, Mark Millard = wrote: > Building = /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc/libc.so.7.full > --- libc.so.7.full --- > building shared library libc.so.7 > /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x3b): = R_AARCH64_ABS64 used with TLS symbol udb > /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x58): = R_AARCH64_ABS64 used with TLS symbol uf > /usr/local/aarch64-freebsd/bin/ld: utxdb.pico(.debug_info+0x5a): = R_AARCH64_ABS64 used with TLS symbol futx_to_utx.ut > /usr/local/aarch64-freebsd/bin/ld: = jemalloc_tsd.pico(.debug_info+0x3c): R_AARCH64_ABS64 used with TLS = symbol __je_tsd_tls > /usr/local/aarch64-freebsd/bin/ld: = jemalloc_tsd.pico(.debug_info+0x146e): R_AARCH64_ABS64 used with TLS = symbol __je_tsd_initialized > /usr/local/aarch64-freebsd/bin/ld: = cxa_thread_atexit_impl.pico(.debug_info+0x3b): R_AARCH64_ABS64 used with = TLS symbol dtors > /usr/local/aarch64-freebsd/bin/ld: xlocale.pico(.debug_info+0x403): = R_AARCH64_ABS64 used with TLS symbol __thread_locale > /usr/local/aarch64-freebsd/bin/ld: = setrunelocale.pico(.debug_info+0x3c): R_AARCH64_ABS64 used with TLS = symbol _ThreadRuneLocale > cc: error: linker command failed with exit code 1 (use -v to see = invocation) >=20 > I also see this on our CI server: = https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/ , this job began = failing since aarch64-binutils upgraded to 2.28 on pkg.freebsd.org. >=20 > Should we revert this change for now? Or the fix is being prepared? I have no clue about any effort to fix the problem. I noticed this after first doing a self-hosted amd64 update. Once I noticed the amd64 -> arm64 problem (the next thing that I tried), I also reverted for targeting armv6/v7 and for targeting powerpc64 and powerpc without testing 2.28 for them. I had to in order to complete targeting arm64 because of the slave-port status that had me revert devel/binutils itself as well. So I do not even know if TARGET_ARCH=3Daarch64 is the only problem area. I've no say in if something like this is reverted but I'd guess that unless the time frame for a fix is known to be rather short it would be reverted until there is an expected-fix available. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Mar 27 09:41:54 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 44FD5D1FC9A; Mon, 27 Mar 2017 09:41:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F5521791; Mon, 27 Mar 2017 09:41:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::5868:2545:a766:52d] (unknown [IPv6:2001:470:7a58:0:5868:2545:a766:52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C84B51F951; Mon, 27 Mar 2017 11:41:50 +0200 (CEST) From: Dimitry Andric Message-Id: <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_42849A06-C7A8-45F6-85FA-EA3552BA4953"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Date: Mon, 27 Mar 2017 11:41:40 +0200 In-Reply-To: <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> Cc: FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current To: Mark Millard References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> X-Mailer: Apple Mail (2.3259) 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: Mon, 27 Mar 2017 09:41:54 -0000 --Apple-Mail=_42849A06-C7A8-45F6-85FA-EA3552BA4953 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 26 Mar 2017, at 23:36, Mark Millard wrote: > > I upgraded from llvm40 r4 to final. An interesting result was > its creation of a backup package for llvm40-4.0.0.r4: > > about 13 cpu-core-hours running pkg create > > (Remember: I've been building with WITH_DEBUG= ) Its > single-threaded status stands out via elapsed time > approximately matching. > > I'll note that it was somewhat under 6 elapsed hours for > staging to have been populated (-j4 with 4 cores present > helps for this part). > > (Of course these elapsed-time figures are rather system > dependent, although the ratio might be more stable.) > > > > Also interesting was: > > Installed packages to be REMOVED: > llvm40-4.0.0.r4 > > Number of packages to be removed: 1 > > The operation will free 49 GiB. Yes, this is big. But there is no real need to build the llvm ports with debug information, unless you want to hack on llvm itself. And in that case, you are better served by a Subversion checkout or Git clone from upstream instead. -Dimitry --Apple-Mail=_42849A06-C7A8-45F6-85FA-EA3552BA4953 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljY3l4ACgkQsF6jCi4glqNxXQCeMmQxz2blw4Ebe9kfnfD2Lgst zswAn1d2KmHqe49pG50RRjWtVnrquJMM =phiU -----END PGP SIGNATURE----- --Apple-Mail=_42849A06-C7A8-45F6-85FA-EA3552BA4953-- From owner-freebsd-toolchain@freebsd.org Mon Mar 27 10:31:48 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 511F5D1FF74 for ; Mon, 27 Mar 2017 10:31:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-182.reflexion.net [208.70.211.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 022C9CF5 for ; Mon, 27 Mar 2017 10:31:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5479 invoked from network); 27 Mar 2017 10:25:06 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 27 Mar 2017 10:25:06 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Mon, 27 Mar 2017 06:25:06 -0400 (EDT) Received: (qmail 7097 invoked from network); 27 Mar 2017 10:25:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Mar 2017 10:25:06 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 9D6F3EC85DE; Mon, 27 Mar 2017 03:25:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> Date: Mon, 27 Mar 2017 03:25:04 -0700 Cc: FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.3259) 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: Mon, 27 Mar 2017 10:31:48 -0000 On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: > On 26 Mar 2017, at 23:36, Mark Millard wrote: >> >> I upgraded from llvm40 r4 to final. An interesting result was >> its creation of a backup package for llvm40-4.0.0.r4: >> >> about 13 cpu-core-hours running pkg create >> >> (Remember: I've been building with WITH_DEBUG= ) Its >> single-threaded status stands out via elapsed time >> approximately matching. >> >> I'll note that it was somewhat under 6 elapsed hours for >> staging to have been populated (-j4 with 4 cores present >> helps for this part). >> >> (Of course these elapsed-time figures are rather system >> dependent, although the ratio might be more stable.) >> >> >> >> Also interesting was: >> >> Installed packages to be REMOVED: >> llvm40-4.0.0.r4 >> >> Number of packages to be removed: 1 >> >> The operation will free 49 GiB. > > Yes, this is big. But there is no real need to build the llvm ports > with debug information, unless you want to hack on llvm itself. And > in that case, you are better served by a Subversion checkout or Git > clone from upstream instead. > > -Dimitry FYI: Historically unless something extreme like this ends up involved I build everything using WITH_DEBUG= or explicit -g's in order to have better information on any failure. This is extreme enough that next time I synchronize /usr/ports and it has a devel/llvm40 update I'll likely rebuild devel/llvm40 without using WITH_DEBUG= . I'm more concerned with the time it takes than with the file system space involved. === Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Mar 27 10:43:00 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 30A17CA1367 for ; Mon, 27 Mar 2017 10:43:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-177.reflexion.net [208.70.211.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D58125ED for ; Mon, 27 Mar 2017 10:42:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5840 invoked from network); 27 Mar 2017 10:42:58 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 Mar 2017 10:42:58 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Mon, 27 Mar 2017 06:42:58 -0400 (EDT) Received: (qmail 26722 invoked from network); 27 Mar 2017 10:42:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Mar 2017 10:42:57 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 34503EC7822; Mon, 27 Mar 2017 03:42:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> Date: Mon, 27 Mar 2017 03:42:56 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD Ports , FreeBSD PowerPC ML Content-Transfer-Encoding: 7bit Message-Id: <849A6761-FF8C-4D28-82C5-4324DED00402@dsl-only.net> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> To: Dimitry Andric X-Mailer: Apple Mail (2.3259) 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: Mon, 27 Mar 2017 10:43:00 -0000 On 2017-Mar-27, at 3:25 AM, Mark Millard wrote: > On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: > >> On 26 Mar 2017, at 23:36, Mark Millard wrote: >>> >>> I upgraded from llvm40 r4 to final. An interesting result was >>> its creation of a backup package for llvm40-4.0.0.r4: >>> >>> about 13 cpu-core-hours running pkg create >>> >>> (Remember: I've been building with WITH_DEBUG= ) Its >>> single-threaded status stands out via elapsed time >>> approximately matching. >>> >>> I'll note that it was somewhat under 6 elapsed hours for >>> staging to have been populated (-j4 with 4 cores present >>> helps for this part). >>> >>> (Of course these elapsed-time figures are rather system >>> dependent, although the ratio might be more stable.) >>> >>> >>> >>> Also interesting was: >>> >>> Installed packages to be REMOVED: >>> llvm40-4.0.0.r4 >>> >>> Number of packages to be removed: 1 >>> >>> The operation will free 49 GiB. >> >> Yes, this is big. But there is no real need to build the llvm ports >> with debug information, unless you want to hack on llvm itself. And >> in that case, you are better served by a Subversion checkout or Git >> clone from upstream instead. >> >> -Dimitry > > FYI: > > Historically unless something extreme like this ends up > involved I build everything using WITH_DEBUG= or explicit > -g's in order to have better information on any failure. > > This is extreme enough that next time I synchronize > /usr/ports and it has a devel/llvm40 update I'll > likely rebuild devel/llvm40 without using WITH_DEBUG= . > I'm more concerned with the time it takes than with > the file system space involved. [Bad example of a incomplete thought. . .] That last presumes a hardware environment with lots of RAM (such as 16 GiBytes) --which I usually do not have access to. Having such is why the report was from a powerpc64 context: that is where I've access to that much RAM for FreeBSD. === Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Mar 27 12:53:48 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 7A131D2043C; Mon, 27 Mar 2017 12:53:48 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42BC6A09; Mon, 27 Mar 2017 12:53:48 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::5868:2545:a766:52d] (unknown [IPv6:2001:470:7a58:0:5868:2545:a766:52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C37DA1F968; Mon, 27 Mar 2017 14:53:45 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_54747A7A-60FC-41AE-A610-0C40033DAA05"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Date: Mon, 27 Mar 2017 14:53:39 +0200 In-Reply-To: <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> Cc: FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current To: Mark Millard References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> X-Mailer: Apple Mail (2.3259) 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: Mon, 27 Mar 2017 12:53:48 -0000 --Apple-Mail=_54747A7A-60FC-41AE-A610-0C40033DAA05 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 27 Mar 2017, at 12:25, Mark Millard wrote: > > On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: >> On 26 Mar 2017, at 23:36, Mark Millard wrote: ... >>> Installed packages to be REMOVED: >>> llvm40-4.0.0.r4 >>> >>> Number of packages to be removed: 1 >>> >>> The operation will free 49 GiB. >> >> Yes, this is big. But there is no real need to build the llvm ports >> with debug information, unless you want to hack on llvm itself. And >> in that case, you are better served by a Subversion checkout or Git >> clone from upstream instead. ... > Historically unless something extreme like this ends up > involved I build everything using WITH_DEBUG= or explicit > -g's in order to have better information on any failure. The problem with the ports implementation of WITH_DEBUG is that it always disables all optimizations, without a possibility to override. Which bloats the resulting object files, libraries and executables, and especially so for large C++ projects such as LLVM. I can recommend the following workaround. If you want to build a port with optimizations disabled, you can always pass -O0 in CFLAGS. -Dimitry Index: Mk/bsd.port.mk =================================================================== --- Mk/bsd.port.mk (revision 436685) +++ Mk/bsd.port.mk (working copy) @@ -1646,7 +1646,7 @@ MAKE_ENV+= DONTSTRIP=yes STRIP_CMD= ${TRUE} .endif DEBUG_FLAGS?= -g -CFLAGS:= ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} +CFLAGS:= ${CFLAGS} ${DEBUG_FLAGS} .if defined(INSTALL_TARGET) INSTALL_TARGET:= ${INSTALL_TARGET:S/^install-strip$/install/g} .endif --Apple-Mail=_54747A7A-60FC-41AE-A610-0C40033DAA05 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljZC1kACgkQsF6jCi4glqNJ9ACaA7mkaSbBsbXWA54kbVSMwc/k vn8AoIAUO0WmGfOZ1OWXdQfDsgreAgpo =6gZ8 -----END PGP SIGNATURE----- --Apple-Mail=_54747A7A-60FC-41AE-A610-0C40033DAA05-- From owner-freebsd-toolchain@freebsd.org Mon Mar 27 14:51:40 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 4A552D20EEC for ; Mon, 27 Mar 2017 14:51:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39DEDC60 for ; Mon, 27 Mar 2017 14:51:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2REpdQR090777 for ; Mon, 27 Mar 2017 14:51:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216707] exp-run: Update lang/gcc from GCC 4.9 to GCC 5 Date: Mon, 27 Mar 2017 14:51:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Ports Framework X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: portmgr@FreeBSD.org X-Bugzilla-Flags: exp-run? X-Bugzilla-Changed-Fields: blocked Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Mon, 27 Mar 2017 14:51:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216707 Jan Beich (mail not working) changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |218125 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218125 [Bug 218125] compiler:c++11-lib feature should choose gcc5+ or clang3x for powerpc64 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Mar 27 21:11:52 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 C72B5D20942 for ; Mon, 27 Mar 2017 21:11:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-182.reflexion.net [208.70.211.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B045E4B for ; Mon, 27 Mar 2017 21:11:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10089 invoked from network); 27 Mar 2017 21:11:51 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 27 Mar 2017 21:11:51 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Mon, 27 Mar 2017 17:11:51 -0400 (EDT) Received: (qmail 15521 invoked from network); 27 Mar 2017 21:11:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Mar 2017 21:11:50 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 00D36EC81C9; Mon, 27 Mar 2017 14:11:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: Date: Mon, 27 Mar 2017 14:11:49 -0700 Cc: FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> To: Dimitry Andric X-Mailer: Apple Mail (2.3259) 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: Mon, 27 Mar 2017 21:11:52 -0000 On 2017-Mar-27, at 5:53 AM, Dimitry Andric wrote: > On 27 Mar 2017, at 12:25, Mark Millard wrote: >>=20 >> On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: >>> On 26 Mar 2017, at 23:36, Mark Millard wrote: > ... >>>> Installed packages to be REMOVED: >>>> llvm40-4.0.0.r4 >>>>=20 >>>> Number of packages to be removed: 1 >>>>=20 >>>> The operation will free 49 GiB. >>>=20 >>> Yes, this is big. But there is no real need to build the llvm ports >>> with debug information, unless you want to hack on llvm itself. And >>> in that case, you are better served by a Subversion checkout or Git >>> clone from upstream instead. > ... >> Historically unless something extreme like this ends up >> involved I build everything using WITH_DEBUG=3D or explicit >> -g's in order to have better information on any failure. >=20 > The problem with the ports implementation of WITH_DEBUG is that it > always disables all optimizations, without a possibility to override. > Which bloats the resulting object files, libraries and executables, = and > especially so for large C++ projects such as LLVM. >=20 > I can recommend the following workaround. If you want to build a port > with optimizations disabled, you can always pass -O0 in CFLAGS. >=20 > -Dimitry >=20 > Index: Mk/bsd.port.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- Mk/bsd.port.mk (revision 436685) > +++ Mk/bsd.port.mk (working copy) > @@ -1646,7 +1646,7 @@ MAKE_ENV+=3D DONTSTRIP=3Dyes > STRIP_CMD=3D ${TRUE} > .endif > DEBUG_FLAGS?=3D -g > -CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} > +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} > .if defined(INSTALL_TARGET) > INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} > .endif Interesting. WITH_DEBUG's description in the file does not mention that stripping of optimization flags: # WITH_DEBUG - If set, debugging flags are added to CFLAGS = and the # binaries don't get stripped by INSTALL_PROGRAM = or # INSTALL_LIB. Besides, individual ports might # add their specific to produce binaries for = debugging # purposes. You can override the debug flags = that are # passed to the compiler by setting DEBUG_FLAGS. = It is # set to "-g" at default. I'll probably give myself an override that I can specify in /etc/make.conf , such as: # svnlite diff /usr/ports/Mk/bsd.port.mk Index: /usr/ports/Mk/bsd.port.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/ports/Mk/bsd.port.mk (revision 436747) +++ /usr/ports/Mk/bsd.port.mk (working copy) @@ -1646,7 +1646,11 @@ STRIP_CMD=3D ${TRUE} .endif DEBUG_FLAGS?=3D -g +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG) +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} +.else CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} +.endif .if defined(INSTALL_TARGET) INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} .endif =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Mar 27 21:40:57 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 1D2BDD20348; Mon, 27 Mar 2017 21:40:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D469A6A; Mon, 27 Mar 2017 21:40:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::5868:2545:a766:52d] (unknown [IPv6:2001:470:7a58:0:5868:2545:a766:52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9C5801F9A6; Mon, 27 Mar 2017 23:40:52 +0200 (CEST) From: Dimitry Andric Message-Id: <7FFF80B9-CE74-49C8-B295-DCB630368152@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_514FBD21-D9EF-4E52-B92E-56F9D9059F6B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Date: Mon, 27 Mar 2017 23:40:45 +0200 In-Reply-To: Cc: FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current To: Mark Millard References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> X-Mailer: Apple Mail (2.3259) 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: Mon, 27 Mar 2017 21:40:57 -0000 --Apple-Mail=_514FBD21-D9EF-4E52-B92E-56F9D9059F6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 27 Mar 2017, at 23:11, Mark Millard wrote: >=20 > On 2017-Mar-27, at 5:53 AM, Dimitry Andric wrote: >> On 27 Mar 2017, at 12:25, Mark Millard = wrote: >>>=20 >>> On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: >>>> On 26 Mar 2017, at 23:36, Mark Millard wrote: >> ... >>>>> Installed packages to be REMOVED: >>>>> llvm40-4.0.0.r4 >>>>>=20 >>>>> Number of packages to be removed: 1 >>>>>=20 >>>>> The operation will free 49 GiB. >>>>=20 >>>> Yes, this is big. But there is no real need to build the llvm = ports >>>> with debug information, unless you want to hack on llvm itself. = And >>>> in that case, you are better served by a Subversion checkout or Git >>>> clone from upstream instead. >> ... >>> Historically unless something extreme like this ends up >>> involved I build everything using WITH_DEBUG=3D or explicit >>> -g's in order to have better information on any failure. >>=20 >> The problem with the ports implementation of WITH_DEBUG is that it >> always disables all optimizations, without a possibility to override. >> Which bloats the resulting object files, libraries and executables, = and >> especially so for large C++ projects such as LLVM. >>=20 >> I can recommend the following workaround. If you want to build a = port >> with optimizations disabled, you can always pass -O0 in CFLAGS. >>=20 >> -Dimitry >>=20 >> Index: Mk/bsd.port.mk >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- Mk/bsd.port.mk (revision 436685) >> +++ Mk/bsd.port.mk (working copy) >> @@ -1646,7 +1646,7 @@ MAKE_ENV+=3D DONTSTRIP=3Dyes >> STRIP_CMD=3D ${TRUE} >> .endif >> DEBUG_FLAGS?=3D -g >> -CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} >> +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} >> .if defined(INSTALL_TARGET) >> INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} >> .endif >=20 > Interesting. WITH_DEBUG's description in the file does not > mention that stripping of optimization flags: >=20 > # WITH_DEBUG - If set, debugging flags are added to CFLAGS = and the > # binaries don't get stripped by = INSTALL_PROGRAM or > # INSTALL_LIB. Besides, individual ports might > # add their specific to produce binaries for = debugging > # purposes. You can override the debug flags = that are > # passed to the compiler by setting = DEBUG_FLAGS. It is > # set to "-g" at default. >=20 > I'll probably give myself an override that I can specify in > /etc/make.conf , such as: >=20 > # svnlite diff /usr/ports/Mk/bsd.port.mk > Index: /usr/ports/Mk/bsd.port.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/ports/Mk/bsd.port.mk (revision 436747) > +++ /usr/ports/Mk/bsd.port.mk (working copy) > @@ -1646,7 +1646,11 @@ > STRIP_CMD=3D ${TRUE} > .endif > DEBUG_FLAGS?=3D -g > +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG) > +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} > +.else > CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} > +.endif > .if defined(INSTALL_TARGET) > INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} > .endif Effectively, this gives some sort of support for three of CMake's build types, e.g: * Debug, which disables optimization, and obviously adds debuginfo * Release, which optimizes for speed, and does not add debuginfo * RelWithDebInfo, similar to Release but does add debuginfo It would be nice if there was some way of directly utilizing these. The RelWithDebInfo target is very useful with the LLVM projects. -Dimitry --Apple-Mail=_514FBD21-D9EF-4E52-B92E-56F9D9059F6B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljZhuQACgkQsF6jCi4glqMorQCgv/7IBqz9jGgFaN9QHYfyAdbR KxEAn0lOODsBULR/lK+hU1IIgZzVItti =v4EU -----END PGP SIGNATURE----- --Apple-Mail=_514FBD21-D9EF-4E52-B92E-56F9D9059F6B-- From owner-freebsd-toolchain@freebsd.org Wed Mar 29 14:54:55 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 83D4CD23238 for ; Wed, 29 Mar 2017 14:54:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 72B5365C3A for ; Wed, 29 Mar 2017 14:54:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2TEssNs032000 for ; Wed, 29 Mar 2017 14:54:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214258] devel/openmp: spurious libm dependency Date: Wed, 29 Mar 2017 14:54:55 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch, regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jbeich@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status blocked assigned_to flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 29 Mar 2017 14:54:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214258 Jan Beich (mail not working) changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed Blocks| |210337 Assignee|freebsd-toolchain@FreeBSD.o |jbeich@FreeBSD.org |rg | Flags|maintainer-feedback?(bapt@F | |reeBSD.org) | --- Comment #12 from Jan Beich (mail not working) --- 2017Q2 is around the corner, so I've landed before upstream review. ;\ https://svnweb.freebsd.org/changeset/ports/437204 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210337 [Bug 210337] [exp-run] allow libiomp for openmp when using clang on amd64 --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Mar 29 15:38:02 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 DBF1CD20130 for ; Wed, 29 Mar 2017 15:38:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA7CC2E5F for ; Wed, 29 Mar 2017 15:38:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2TFc2i9047864 for ; Wed, 29 Mar 2017 15:38:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214855] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based cross build: powerpc.powerpc64/usr/src/tmp/usr/bin/ld: BFD 2.17.50 [FreeBSD] 2007-07-03 internal error Date: Wed, 29 Mar 2017 15:38:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhibbits@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 29 Mar 2017 15:38:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214855 Justin Hibbits changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhibbits@FreeBSD.org --- Comment #4 from Justin Hibbits --- I saw this back in 2014 when I was making my first set of changes for the n= ew thread local storage relocations that clang uses. I was never able to track down the bug yet, and haven't tested to see if it manifests as well with ne= wer binutils. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Mar 29 15:53:24 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 0C532D20E16; Wed, 29 Mar 2017 15:53:24 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C16A567685; Wed, 29 Mar 2017 15:53:23 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 649735A9F15; Wed, 29 Mar 2017 15:53:16 +0000 (UTC) Date: Wed, 29 Mar 2017 15:53:16 +0000 From: Brooks Davis To: Mark Millard Cc: Dimitry Andric , FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Message-ID: <20170329155316.GK59667@spindle.one-eyed-alien.net> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m1UC1K4AOz1Ywdkx" Content-Disposition: inline In-Reply-To: <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> User-Agent: Mutt/1.7.2 (2016-11-26) 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, 29 Mar 2017 15:53:24 -0000 --m1UC1K4AOz1Ywdkx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote: > On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: >=20 > > On 26 Mar 2017, at 23:36, Mark Millard wrote: > >>=20 > >> I upgraded from llvm40 r4 to final. An interesting result was > >> its creation of a backup package for llvm40-4.0.0.r4: > >>=20 > >> about 13 cpu-core-hours running pkg create > >>=20 > >> (Remember: I've been building with WITH_DEBUG=3D ) Its > >> single-threaded status stands out via elapsed time > >> approximately matching. > >>=20 > >> I'll note that it was somewhat under 6 elapsed hours for > >> staging to have been populated (-j4 with 4 cores present > >> helps for this part). > >>=20 > >> (Of course these elapsed-time figures are rather system > >> dependent, although the ratio might be more stable.) > >>=20 > >>=20 > >>=20 > >> Also interesting was: > >>=20 > >> Installed packages to be REMOVED: > >> llvm40-4.0.0.r4 > >>=20 > >> Number of packages to be removed: 1 > >>=20 > >> The operation will free 49 GiB. > >=20 > > Yes, this is big. But there is no real need to build the llvm ports > > with debug information, unless you want to hack on llvm itself. And > > in that case, you are better served by a Subversion checkout or Git > > clone from upstream instead. > >=20 > > -Dimitry >=20 > FYI: >=20 > Historically unless something extreme like this ends up > involved I build everything using WITH_DEBUG=3D or explicit > -g's in order to have better information on any failure. >=20 > This is extreme enough that next time I synchronize > /usr/ports and it has a devel/llvm40 update I'll > likely rebuild devel/llvm40 without using WITH_DEBUG=3D . > I'm more concerned with the time it takes than with > the file system space involved. In the case of LLVM, enabling debug builds does a LOT more than adding symbols. It's much more like enabling WITNESS and INVARIANTS in your kernel, except that the performance of the resulting binary is much worse than a WITNESS kernel (more like 10x slowdown). As Dimitry points out, these builds are of questionable value in ports so garbage collecting the knob might be the sensable thing to do. -- Brooks --m1UC1K4AOz1Ywdkx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJY29hrAAoJEKzQXbSebgfA6cgH/1FWA1dO2yctl/WJzfe4cF2E 1QRc3LUXX/DR9NktYS1GyLUJvgSncqNBMTBIwgeto5JxESn5A9fwry9L3koVCNFC GyjK+y1mNakVnZsFpe42QxKg53xv2Mi2ummNuatebC23a6ari++l/ioPIpR0tI+h nXRlH+PQYmXRnZvFoB2knVOXp5U++UkeoqJ0RnT17hHnwvLVwMlRdFyC+IoAuVZb xHb7bwm7yk0zo66onLfMcuj7MlIOgncg5l6KB42MTh6uIKY23LNl3qYernRbodnj 9t6eKI1mnD3nA10G8b0MBoUoDPb9/MkubIm4jRC1ag0k7Dj7YdHE8Wh/pLOyfxY= =MI2X -----END PGP SIGNATURE----- --m1UC1K4AOz1Ywdkx-- From owner-freebsd-toolchain@freebsd.org Wed Mar 29 17:25:59 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 6F359D231E0; Wed, 29 Mar 2017 17:25:59 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 375C267E56; Wed, 29 Mar 2017 17:25:59 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::416b:f3a0:99b:694b] (unknown [IPv6:2001:470:7a58:0:416b:f3a0:99b:694b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D12B315014; Wed, 29 Mar 2017 19:25:47 +0200 (CEST) From: Dimitry Andric Message-Id: <779FB7DC-C041-43CD-ADF2-1F5D791832A6@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_EE11392F-FEC5-4555-BA6C-B9AB94FCAF35"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) 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, 29 Mar 2017 19:25:43 +0200 In-Reply-To: <20170329155316.GK59667@spindle.one-eyed-alien.net> Cc: Mark Millard , FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current To: Brooks Davis References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> <20170329155316.GK59667@spindle.one-eyed-alien.net> X-Mailer: Apple Mail (2.3273) 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, 29 Mar 2017 17:25:59 -0000 --Apple-Mail=_EE11392F-FEC5-4555-BA6C-B9AB94FCAF35 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 29 Mar 2017, at 17:53, Brooks Davis wrote: > > On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote: ... >> This is extreme enough that next time I synchronize >> /usr/ports and it has a devel/llvm40 update I'll >> likely rebuild devel/llvm40 without using WITH_DEBUG= . >> I'm more concerned with the time it takes than with >> the file system space involved. > > In the case of LLVM, enabling debug builds does a LOT more than adding > symbols. It's much more like enabling WITNESS and INVARIANTS in your > kernel, except that the performance of the resulting binary is much > worse than a WITNESS kernel (more like 10x slowdown). > > As Dimitry points out, these builds are of questionable value in ports > so garbage collecting the knob might be the sensable thing to do. I suggest that for the LLVM ports, the DEBUG option should set the RelWithDebInfo build type for CMake. That will give you binaries which can produce good backtraces, and a fair chance at debugging, in a pinch. -Dimitry --Apple-Mail=_EE11392F-FEC5-4555-BA6C-B9AB94FCAF35 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljb7hsACgkQsF6jCi4glqNTCACghnz91bTIcsVeRILZ8G99/Qr1 QIEAn3G5vr5EwRwJ5DqfnQmJC130xw+Y =Nno0 -----END PGP SIGNATURE----- --Apple-Mail=_EE11392F-FEC5-4555-BA6C-B9AB94FCAF35-- From owner-freebsd-toolchain@freebsd.org Wed Mar 29 18:37:48 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 19342D24DD4 for ; Wed, 29 Mar 2017 18:37:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 08B2C1B01 for ; Wed, 29 Mar 2017 18:37:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2TIbl1d007277 for ; Wed, 29 Mar 2017 18:37:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214258] devel/openmp: spurious libm dependency Date: Wed, 29 Mar 2017 18:37:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch, regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jbeich@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 29 Mar 2017 18:37:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214258 --- Comment #13 from commit-hook@freebsd.org --- A commit references this bug: Author: jbeich Date: Wed Mar 29 14:43:30 UTC 2017 New revision: 437204 URL: https://svnweb.freebsd.org/changeset/ports/437204 Log: devel/openmp: link libomp.so against -lm for clang 3.6+ PR: 214258 Submitted by: Yuta Satoh Approved by: portmgr blanket Changes: head/devel/llvm-devel/Makefile head/devel/llvm-devel/files/openmp-patch-bug32279 head/devel/llvm37/Makefile head/devel/llvm37/files/openmp-patch-bug32279 head/devel/llvm38/Makefile head/devel/llvm38/files/openmp-patch-bug32279 head/devel/llvm39/Makefile head/devel/llvm39/files/openmp-patch-bug32279 head/devel/llvm40/Makefile head/devel/llvm40/files/openmp-patch-bug32279 head/devel/openmp/Makefile head/devel/openmp/files/patch-bug32279 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Mar 29 21:44:02 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 CC6ABD2423E for ; Wed, 29 Mar 2017 21:44:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BAE94E01 for ; Wed, 29 Mar 2017 21:44:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2TLi2Kr077823 for ; Wed, 29 Mar 2017 21:44:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214855] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based cross build: powerpc.powerpc64/usr/src/tmp/usr/bin/ld: BFD 2.17.50 [FreeBSD] 2007-07-03 internal error Date: Wed, 29 Mar 2017 21:44:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 29 Mar 2017 21:44:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214855 --- Comment #5 from Mark Millard --- (In reply to Justin Hibbits from comment #4) ld from 2.25 and from 2.27 from ports has worked fine. But I'm not sure if by "newer" Justin was referring to such vs. referring to potential updates to the system 2.17.* ld. While code that handles thrown C++ exceptions fails at run-time I'm able to use clang to buildworld and boot and use FreeBSD for powerpc64 based on the ports binutils (although I've not tried the new 2.28). [I reverted to 2.27 when I found that arm64/aarch64 was broken for buildworld buildkernel (at least for cross building from amd64). I did this before trying powerpc64 or powerpc.] [Unfortunately without C++ exception handling working kyua can not be used on powerpc64. In my view that is sufficient to say that clang is still insufficient to be the system compiler for powerpc64 --ignoring any system binutils or lld issues hat force port binutils use.] --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Mar 30 17:06:49 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 54192D26F6C; Thu, 30 Mar 2017 17:06:49 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 3167C1D6; Thu, 30 Mar 2017 17:06:49 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 755D742BA; Thu, 30 Mar 2017 17:06:48 +0000 (UTC) Date: Thu, 30 Mar 2017 17:06:48 +0000 From: Alexey Dokuchaev To: Dimitry Andric Cc: Mark Millard , Johannes M Dieterich , Matthew Rezny , 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) Message-ID: <20170330170648.GA38004@FreeBSD.org> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> User-Agent: Mutt/1.7.1 (2016-10-04) 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: Thu, 30 Mar 2017 17:06:49 -0000 On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote: > On 26 Mar 2017, at 23:36, Mark Millard wrote: > > ... > > Also interesting was: > > > > Installed packages to be REMOVED: > > llvm40-4.0.0.r4 > > > > Number of packages to be removed: 1 > > > > The operation will free 49 GiB. > > Yes, this is big. But there is no real need to build the llvm ports > with debug information, unless you want to hack on llvm itself. Cc'ing jmd@ and rezny@. I've been watching increasing size of our LLVM packages with increasing worry. This is from my tinderbox cache: $ % env LANG=C ls -lh llvm3* -rw-r--r-- 1 root wheel 17M Jan 29 2016 llvm35-3.5.2_1.txz -rw-r--r-- 1 root wheel 18M Mar 7 2016 llvm36-3.6.2_2.txz -rw-r--r-- 1 root wheel 27M Feb 28 01:05 llvm37-3.7.1_4.txz -rw-r--r-- 1 root wheel 207M Jan 19 18:20 llvm38-3.8.1_5.txz -rw-r--r-- 1 root wheel 244M Mar 23 16:42 llvm39-3.9.1_2.txz Dimitry, do you know what had causes such a huge bump in 37 -> 38? They take lots of time to build and package. And given that llvm is indirect dependency of any X11-related port, it pessimises their build times as well (devel/libclc now requires devel/llvm40 after r437268). With 49 GiB llvm40, I guess I won't be able to build-test post as my hardware would just not be capable enough. ./danfe From owner-freebsd-toolchain@freebsd.org Thu Mar 30 17:26:41 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 8B4E0D26804; Thu, 30 Mar 2017 17:26:41 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1658D6F1; Thu, 30 Mar 2017 17:26:40 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::6071:fd3d:eb67:3bb1] (unknown [IPv6:2001:470:7a58:0:6071:fd3d:eb67:3bb1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 06975150D4; Thu, 30 Mar 2017 19:26:31 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F55303D9-0BDF-4643-A726-2AE9AE62151C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Date: Thu, 30 Mar 2017 19:26:19 +0200 In-Reply-To: <20170330170648.GA38004@FreeBSD.org> Cc: Mark Millard , Johannes M Dieterich , Matthew Rezny , FreeBSD Current , FreeBSD Toolchain , FreeBSD Ports , FreeBSD PowerPC ML To: Alexey Dokuchaev References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> X-Mailer: Apple Mail (2.3273) 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: Thu, 30 Mar 2017 17:26:41 -0000 --Apple-Mail=_F55303D9-0BDF-4643-A726-2AE9AE62151C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 30 Mar 2017, at 19:06, Alexey Dokuchaev wrote: >=20 > On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote: >> On 26 Mar 2017, at 23:36, Mark Millard wrote: >>> ... >>> Also interesting was: >>>=20 >>> Installed packages to be REMOVED: >>> llvm40-4.0.0.r4 >>>=20 >>> Number of packages to be removed: 1 >>>=20 >>> The operation will free 49 GiB. >>=20 >> Yes, this is big. But there is no real need to build the llvm ports >> with debug information, unless you want to hack on llvm itself. >=20 > Cc'ing jmd@ and rezny@. >=20 > I've been watching increasing size of our LLVM packages with = increasing > worry. This is from my tinderbox cache: >=20 > $ % env LANG=3DC ls -lh llvm3* > -rw-r--r-- 1 root wheel 17M Jan 29 2016 llvm35-3.5.2_1.txz > -rw-r--r-- 1 root wheel 18M Mar 7 2016 llvm36-3.6.2_2.txz > -rw-r--r-- 1 root wheel 27M Feb 28 01:05 llvm37-3.7.1_4.txz > -rw-r--r-- 1 root wheel 207M Jan 19 18:20 llvm38-3.8.1_5.txz > -rw-r--r-- 1 root wheel 244M Mar 23 16:42 llvm39-3.9.1_2.txz >=20 > Dimitry, do you know what had causes such a huge bump in 37 -> 38? Yes, up to llvm37, the ports were split in devel/llvmXY and lang/clangXY parts, with separate ports for e.g. compiler-rt and other LLVM projects. For llvm38 and later, the devel/llvmXY port contains almost *all* upstream LLVM components, which are then selectable at port configure time. For instance, devel/llvm40 shows: = =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 = llvm40-4.0.0 = =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=90 =E2=94=82 = =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=90 =E2=94=82 =E2=94=82 =E2=94=82 [x] CLANG Build clang = =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 [x] COMPILER_RT Sanitizer libraries = =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 [x] DOCS Build and/or install documentation = =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 [x] EXTRAS Extra clang tools = =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 [x] GOLD Build the LLVM Gold plugin for LTO = =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 [x] LIT Install lit and FileCheck test = tools =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 [x] LLD Install lld, the LLVM linker = =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 [x] LLDB Install lldb, the LLVM debugger = (ignored on 9.x) =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=82 [x] OPENMP Install libomp, the LLVM OpenMP = runtime library =E2=94=82 =E2=94=82 =E2=94=82 = =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=98 =E2=94=82 = =E2=94=9C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=A4 =E2=94=82 < OK > = =E2=94=82 = =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98 If you want to reduce the size of the package, only select the part(s) you need. I think you can get by with just the CLANG option, for most dependent ports. > They take lots of time to build and package. And given that llvm > is indirect dependency of any X11-related port, it pessimises their > build times as well (devel/libclc now requires devel/llvm40 after > r437268). The previous split looks pretty hard to maintain, so that is most likely the reason for combining all components in one port after 3.8. Unfortunately the side effect is that it is way less granular. If we ever get infrastructure for generating multiple packages out of one port, the devel/llvm* ports are very good candidates. :) > With 49 GiB llvm40, I guess I won't be able to build-test post as my > hardware would just not be capable enough. 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. -Dimitry --Apple-Mail=_F55303D9-0BDF-4643-A726-2AE9AE62151C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljdP8gACgkQsF6jCi4glqPpTQCfWKrhpPQ3itwI8ayvAi2wiv1m HoIAoNyxWbVgd3qM9nxp54fU42E7oxkx =5acw -----END PGP SIGNATURE----- --Apple-Mail=_F55303D9-0BDF-4643-A726-2AE9AE62151C-- From owner-freebsd-toolchain@freebsd.org Thu Mar 30 17:26:44 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 E172DD2685E; Thu, 30 Mar 2017 17:26:44 +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 BCB9A773; Thu, 30 Mar 2017 17:26:44 +0000 (UTC) (envelope-from rezny@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1406) id 14ED14A61; Thu, 30 Mar 2017 17:26:44 +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: Thu, 30 Mar 2017 19:26:43 +0200 Message-ID: <2502554.oHoOYGyFJH@workstation.reztek> Organization: FreeBSD User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20170330170648.GA38004@FreeBSD.org> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@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: Thu, 30 Mar 2017 17:26:45 -0000 On Thursday 30 March 2017 17:06:48 Alexey Dokuchaev wrote: > On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote: > > On 26 Mar 2017, at 23:36, Mark Millard wrote: > > > ... > > > Also interesting was: > > > > > > Installed packages to be REMOVED: > > > llvm40-4.0.0.r4 > > > > > > Number of packages to be removed: 1 > > > > > > The operation will free 49 GiB. > > > > Yes, this is big. But there is no real need to build the llvm ports > > with debug information, unless you want to hack on llvm itself. > > Cc'ing jmd@ and rezny@. > > I've been watching increasing size of our LLVM packages with increasing > worry. This is from my tinderbox cache: > > $ % env LANG=C ls -lh llvm3* > -rw-r--r-- 1 root wheel 17M Jan 29 2016 llvm35-3.5.2_1.txz > -rw-r--r-- 1 root wheel 18M Mar 7 2016 llvm36-3.6.2_2.txz > -rw-r--r-- 1 root wheel 27M Feb 28 01:05 llvm37-3.7.1_4.txz > -rw-r--r-- 1 root wheel 207M Jan 19 18:20 llvm38-3.8.1_5.txz > -rw-r--r-- 1 root wheel 244M Mar 23 16:42 llvm39-3.9.1_2.txz > > Dimitry, do you know what had causes such a huge bump in 37 -> 38? > > They take lots of time to build and package. And given that llvm > is indirect dependency of any X11-related port, it pessimises their > build times as well (devel/libclc now requires devel/llvm40 after > r437268). > > With 49 GiB llvm40, I guess I won't be able to build-test post as my > hardware would just not be capable enough. > > ./danfe 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 devs state that static linking the LLVM binaries is only for developer use, users should not do that. Mesa's need was causing distributions to ship static linked LLVM binaries against that advice. So, they added a pair of switches so that we can separately control whether that library is built (required for Mesa) and used to link LLVM binaries (not desired). llvm{35,36,37} are statically linked and thus smaller than normal. llvm38 switched to dynamic linking, the default, thus the size grew. llvm39 added the library Mesa needs (we didn't turn on the option in llvm38 since Mesa jumped from 37 to 39), so it grew a little more. I assume llvm40 will be a bit bigger, but do not expect to see another jump as you've observed. From owner-freebsd-toolchain@freebsd.org Thu Mar 30 17:55:28 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 13501D26412; Thu, 30 Mar 2017 17:55:28 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C449D1B5; Thu, 30 Mar 2017 17:55:27 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id B6AA45A9F15; Thu, 30 Mar 2017 17:55:19 +0000 (UTC) Date: Thu, 30 Mar 2017 17:55:19 +0000 From: Brooks Davis To: Dimitry Andric Cc: Alexey Dokuchaev , FreeBSD Current , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Ports , Johannes M Dieterich , Matthew Rezny Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Message-ID: <20170330175519.GA34411@spindle.one-eyed-alien.net> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) 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: Thu, 30 Mar 2017 17:55:28 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 30, 2017 at 07:26:19PM +0200, Dimitry Andric wrote: > On 30 Mar 2017, at 19:06, Alexey Dokuchaev wrote: > >=20 > > On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote: > >> On 26 Mar 2017, at 23:36, Mark Millard wrote: > >>> ... > >>> Also interesting was: > >>>=20 > >>> Installed packages to be REMOVED: > >>> llvm40-4.0.0.r4 > >>>=20 > >>> Number of packages to be removed: 1 > >>>=20 > >>> The operation will free 49 GiB. > >>=20 > >> Yes, this is big. But there is no real need to build the llvm ports > >> with debug information, unless you want to hack on llvm itself. > >=20 > > Cc'ing jmd@ and rezny@. > >=20 > > I've been watching increasing size of our LLVM packages with increasing > > worry. This is from my tinderbox cache: > >=20 > > $ % env LANG=3DC ls -lh llvm3* > > -rw-r--r-- 1 root wheel 17M Jan 29 2016 llvm35-3.5.2_1.txz > > -rw-r--r-- 1 root wheel 18M Mar 7 2016 llvm36-3.6.2_2.txz > > -rw-r--r-- 1 root wheel 27M Feb 28 01:05 llvm37-3.7.1_4.txz > > -rw-r--r-- 1 root wheel 207M Jan 19 18:20 llvm38-3.8.1_5.txz > > -rw-r--r-- 1 root wheel 244M Mar 23 16:42 llvm39-3.9.1_2.txz > >=20 > > Dimitry, do you know what had causes such a huge bump in 37 -> 38? >=20 > Yes, up to llvm37, the ports were split in devel/llvmXY and lang/clangXY > parts, with separate ports for e.g. compiler-rt and other LLVM projects. It's mostly that we build both shared and static libraries. llvm37 merged clang and llvm (with a clang37 metaport). Dynamic builds were broken for a while too which blew up program size. > > They take lots of time to build and package. And given that llvm > > is indirect dependency of any X11-related port, it pessimises their > > build times as well (devel/libclc now requires devel/llvm40 after > > r437268). >=20 > The previous split looks pretty hard to maintain, so that is most likely > the reason for combining all components in one port after 3.8. > Unfortunately the side effect is that it is way less granular. I kept it up for several revisions past when it was desupported, but it's absolutly impossible with the cmake infrastructure unless we want want to build all of LLVM four times to get clang, llvm, lldb, and lld. I'm pretty sure that would case more complaints. :) > If we ever get infrastructure for generating multiple packages out of > one port, the devel/llvm* ports are very good candidates. :) Very much so. > > With 49 GiB llvm40, I guess I won't be able to build-test post as my > > hardware would just not be capable enough. >=20 > 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. -- Brooks 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. --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJY3UaGAAoJEKzQXbSebgfAkBMIAIN/F/30yZoenplFbYojBOM2 J7c3G/3Gey/MbnSPpZtiXBUnmZ110yBviXv570T1+CXR1g0DNXUTsdfV4S1aw7Pm 2EfGY53bfTphWkckadGRyYSeH9lNAP4POj0UXCs28gS+7LB9HkJ+U0Gt7VfFNQhu xxHuTFbGUBso6Cgu7gDAsYaboNxoWqO6l3oTzCOoM38xgHkTQAYfhZs8fbZdaGK7 QT81QTQBvE9k/p+6j4jE+KWfFG4L7PZzZuM+hAGv7Mu5PmYfXcx0BzAmNtPyCRpc i9/uSjLFbP7bdn2Y48+6I2lLNUcGudouFJW1tQBhvd3yjkEYhkRux5hCRsiG7vo= =vLBg -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-toolchain@freebsd.org Thu Mar 30 19:29:46 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 F1477D26852 for ; Thu, 30 Mar 2017 19:29:46 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9CD37BA; Thu, 30 Mar 2017 19:29:46 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x234.google.com with SMTP id e75so339945itd.1; Thu, 30 Mar 2017 12:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=EsjwmqntLtnl3ZKKVUK/ZeKbp9C5ZBt52cI1w6wCxPo=; b=Zy4gGzHDpAVqDRwNrFKEPt4ytjFJ8364UaOuo2ZFe5grgZ8gj3Z6altK7rH9DRK1rq 74KnU3zN+HDZkfo1iSuLdlnl4XkC5l0SeBMxwOwmjodTq+KnTpxtG4XDw7fUJd24Wj1S W7Ruhe4oL3JmdsR/JHv+AM+K5Th1Il3ZH8zPP1KT8BIxfR6DPaWRMUNrX2677e+gc+ZE 9QFNO51kgwRUNo9JU6vlMgFgrUBemDfwxWgN5jg6dxL0rlgywsXW80HqyvjUf4tJ9WeK 79qz5PYDVtg9vvJxonh7gv35giP3UDXPwYzQb2l44Lges6DCXQoWgZuKQFnQAq4qr5F7 M9zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=EsjwmqntLtnl3ZKKVUK/ZeKbp9C5ZBt52cI1w6wCxPo=; b=dnL28zjOzNVZJNjiQdIwPBwCwPrs/seAlvgKA0PWERXSKEvvtpBJLgxRw0u9Ou3FXS FmJXMikjMj/pMJF+Cixa3d4h9/syMQp8flwIpJadyf3pFJYRwkCTAzbxkkdMbGMcxp9G 5A2HZ9a89+K0PP3y6PmTCPcwJ9plYDMhJkiGftN3T73bnkQfYHKaFlhLPpUq64Mx+SDR puEdjSUEYQ2k4r8cgDXCcn+LZniHmXrZdjRhYaNU/9Dj7OT+zTSzs3v0U+qPcTzqsVpO yiBgK6+ahA9F9RFQteqC/vnAMUxECAmYVlS6/G0Q35Ejaq0WRccj2BDSHZed79llr2IR 6lFg== X-Gm-Message-State: AFeK/H0d1UaNxt+CK6wJkGfXitXyFDcWmHVBOnVUAX21YidhDi7Yvqxst1y7N/+pSNYYQAkBRGoT34SRaX9EbA== X-Received: by 10.36.125.143 with SMTP id b137mr2547059itc.4.1490902186027; Thu, 30 Mar 2017 12:29:46 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.30.209 with HTTP; Thu, 30 Mar 2017 12:29:25 -0700 (PDT) In-Reply-To: <20170324122129.GA24947@bali> References: <1612271904400.79526@mx5.roble.com> <20170324122129.GA24947@bali> From: Ed Maste Date: Thu, 30 Mar 2017 15:29:25 -0400 X-Google-Sender-Auth: u8yVtRh30tN0eNDoLny0O9R6Tak Message-ID: Subject: Re: /tmp/ecp.* created during kernel build? To: Andre Albsmeier Cc: Dimitry Andric , "freebsd-toolchain@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 30 Mar 2017 19:29:47 -0000 [redirected to freebsd-toolchain] On 24 March 2017 at 08:21, Andre Albsmeier wr= ote: > > Interesting is also that libc.a grows(!): > > Before the strip: > -r--r----- 1 andre wheel 2622684 24 Mar 13:18 libc.a > > After: > -r--r----- 1 andre wheel 2713792 24 Mar 13:19 libc.a It seems this is a side effect of the way elfcopy writes the new archive and objects. Using diffoscope to compare libc.a and a stripped libc.a we see a few interesting things: % objcopy --strip-debug /usr/lib/libc.a libc.strip1.a % diffoscope /usr/lib/libc.a libc.strip1.a --- /usr/lib/libc.a +++ libc.strip1.a =E2=94=9C=E2=94=80=E2=94=80 file list =E2=94=82 @@ -1,1258 +1,1258 @@ =E2=94=82 ----------- 0 0 0 83210 1970-01-01 00:00:00.00= 0000 / =E2=94=82 +---------- 0 0 0 83210 2017-03-30 19:01:14.00= 0000 / * Elfcopy is updating the timestamp on the "/" entry, despite leaving all other archive metadata alone. =E2=94=82 --rw-r--r-- 0 0 0 1104 1970-01-01 00:00:00.000000 iconvlist.o =E2=94=82 +-rw-r--r-- 0 0 0 1184 1970-01-01 00:00:00.000000 iconvlist.o * As you discovered output is larger, and this is true for the individual .o files in the .a archive. =E2=94=82 File: lib.a(iconvctl.o) =E2=94=82 ELF Header: =E2=94=82 Magic: 7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00 =E2=94=82 Class: ELF64 =E2=94=82 Data: 2's complement, little endi= an =E2=94=82 Version: 1 (current) =E2=94=82 OS/ABI: FreeBSD =E2=94=82 ABI Version: 0 =E2=94=82 Type: REL (Relocatable file) =E2=94=82 Machine: Advanced Micro Devices x86-= 64 =E2=94=82 Version: 0x1 =E2=94=82 Entry point address: 0 =E2=94=82 Start of program headers: 0 (bytes into file) =E2=94=82 - Start of section headers: 528 (bytes into file) =E2=94=82 + Start of section headers: 536 (bytes into file) =E2=94=82 Flags: 0 =E2=94=82 Size of this header: 64 (bytes) =E2=94=82 Size of program headers: 0 (bytes) =E2=94=82 Number of program headers: 0 =E2=94=82 Size of section headers: 64 (bytes) =E2=94=82 - Number of section headers: 9 =E2=94=82 - Section header string table index: 1 =E2=94=82 + Number of section headers: 10 =E2=94=82 + Section header string table index: 9 Section headers are at a different offset, elfcopy/strip output has an extra section. =E2=94=9C=E2=94=80=E2=94=80 readelf --wide --sections {} =E2=94=82 @@ -1,23384 +1,24634 @@ =E2=94=82 =E2=94=82 File: lib.a(iconvlist.o) =E2=94=82 -There are 9 section headers, starting at offset 0x210: =E2=94=82 +There are 10 section headers, starting at offset 0x220: =E2=94=82 =E2=94=82 Section Headers: =E2=94=82 [Nr] Name Type Addr Off Size ES Flg Lk Inf Al =E2=94=82 [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 =E2=94=82 - [ 1] .strtab STRTAB 0000000000000000 000180 00008c 00 0 0 1 =E2=94=82 - [ 2] .text PROGBITS 0000000000000000 000040 00000a 00 AX 0 0 16 =E2=94=82 - [ 3] .rela.text RELA 0000000000000000 000150 000018 18 8 2 8 =E2=94=82 - [ 4] .comment PROGBITS 0000000000000000 00004a 000053 01 MS 0 0 1 =E2=94=82 - [ 5] .note.GNU-stack PROGBITS 0000000000000000 00009d 000000 00 0 0 1 =E2=94=82 - [ 6] .eh_frame X86_64_UNWIND 0000000000000000 0000a0 000038 00 A 0 0 8 =E2=94=82 - [ 7] .rela.eh_frame RELA 0000000000000000 000168 000018 18 8 6 8 =E2=94=82 - [ 8] .symtab SYMTAB 0000000000000000 0000d8 000078 18 1 3 8 =E2=94=82 + [ 1] .text PROGBITS 0000000000000000 000040 00000a 00 AX 0 0 16 =E2=94=82 + [ 2] .rela.text RELA 0000000000000000 000180 000018 18 I 7 1 8 =E2=94=82 + [ 3] .comment PROGBITS 0000000000000000 00004a 000053 01 MS 0 0 1 =E2=94=82 + [ 4] .note.GNU-stack PROGBITS 0000000000000000 00009d 000000 00 0 0 1 =E2=94=82 + [ 5] .eh_frame X86_64_UNWIND 0000000000000000 0000a0 000038 00 A 0 0 8 =E2=94=82 + [ 6] .rela.eh_frame RELA 0000000000000000 000198 000018 18 I 7 5 8 =E2=94=82 + [ 7] .symtab SYMTAB 0000000000000000 0000d8 0000a8 18 8 5 8 =E2=94=82 + [ 8] .strtab STRTAB 0000000000000000 0001b0 00001b 00 0 0 1 =E2=94=82 + [ 9] .shstrtab STRTAB 0000000000000000 0001cb 00004e 00 0 0 1 =E2=94=82 Key to Flags: =E2=94=82 W (write), A (alloc), X (execute), M (merge), S (strings) =E2=94=82 I (info), L (link order), G (group), x (unknown) =E2=94=82 O (extra OS processing required) o (OS specific), p (processor= specific) Sections are in a different order, and elfcopy/strip includes a separate section header string table, while Clang's output stores both symbol names and names used in the section header in .strtab. The increased size is interesting and somewhat unfortunate, but not necessarily a bug. > strip (objcopy) does more curious things: > > $ cd /tmp > $ cp /usr/lib/libc.a . > $ strip --strip-debug libc.a > $ strip --strip-debug libc.a > > [1] 960 segmentation fault strip --strip-debug libc.a This is also reproducible as: % objcopy --strip-debug /usr/lib/libc.a libc.1.a % objcopy --strip-debug libc.1.a libc.2.a zsh: bus error (core dumped) objcopy --strip-debug libc.1.a libc.2.a It wasn't reproducible in some trivial cases I tried though (e.g. .a archive with two trivial .o objects), or with some other .a archives: % objcopy --strip-debug /usr/lib/libm.a libm.1.a % objcopy --strip-debug libm.1.a libm.2.a % I've submitted ELF Tool Chain ticket #548 for this issue https://sourceforge.net/p/elftoolchain/tickets/548/ From owner-freebsd-toolchain@freebsd.org Thu Mar 30 20:49:01 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 ED8B3D26621 for ; Thu, 30 Mar 2017 20:49:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-14.reflexion.net [208.70.210.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 99F18C27 for ; Thu, 30 Mar 2017 20:49:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25449 invoked from network); 30 Mar 2017 20:22:19 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 30 Mar 2017 20:22:19 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Thu, 30 Mar 2017 16:22:19 -0400 (EDT) Received: (qmail 2257 invoked from network); 30 Mar 2017 20:22:19 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Mar 2017 20:22:19 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B6849EC8807; Thu, 30 Mar 2017 13:22:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: <20170329155316.GK59667@spindle.one-eyed-alien.net> Date: Thu, 30 Mar 2017 13:22:17 -0700 Cc: FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> <20170329155316.GK59667@spindle.one-eyed-alien.net> To: Brooks Davis , Dimitry Andric X-Mailer: Apple Mail (2.3273) 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: Thu, 30 Mar 2017 20:49:02 -0000 On 2017-Mar-29, at 8:53 AM, Brooks Davis wrote: > On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote: >> On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: >> >>> On 26 Mar 2017, at 23:36, Mark Millard wrote: >>>> >>>> I upgraded from llvm40 r4 to final. An interesting result was >>>> its creation of a backup package for llvm40-4.0.0.r4: >>>> >>>> about 13 cpu-core-hours running pkg create >>>> >>>> (Remember: I've been building with WITH_DEBUG= ) Its >>>> single-threaded status stands out via elapsed time >>>> approximately matching. >>>> >>>> I'll note that it was somewhat under 6 elapsed hours for >>>> staging to have been populated (-j4 with 4 cores present >>>> helps for this part). >>>> >>>> (Of course these elapsed-time figures are rather system >>>> dependent, although the ratio might be more stable.) >>>> >>>> >>>> >>>> Also interesting was: >>>> >>>> Installed packages to be REMOVED: >>>> llvm40-4.0.0.r4 >>>> >>>> Number of packages to be removed: 1 >>>> >>>> The operation will free 49 GiB. >>> >>> Yes, this is big. But there is no real need to build the llvm ports >>> with debug information, unless you want to hack on llvm itself. And >>> in that case, you are better served by a Subversion checkout or Git >>> clone from upstream instead. >>> >>> -Dimitry >> >> FYI: >> >> Historically unless something extreme like this ends up >> involved I build everything using WITH_DEBUG= or explicit >> -g's in order to have better information on any failure. >> >> This is extreme enough that next time I synchronize >> /usr/ports and it has a devel/llvm40 update I'll >> likely rebuild devel/llvm40 without using WITH_DEBUG= . >> I'm more concerned with the time it takes than with >> the file system space involved. > > In the case of LLVM, enabling debug builds does a LOT more than adding > symbols. It's much more like enabling WITNESS and INVARIANTS in your > kernel, except that the performance of the resulting binary is much > worse than a WITNESS kernel (more like 10x slowdown). > > As Dimitry points out, these builds are of questionable value in ports > so garbage collecting the knob might be the sensable thing to do. Sounds like the ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG technique would not change the "WITNESS and INVARIANTS"-like part of the issue. In fact if WITH_DEBUG= causes the cmake debug-style llvm40 build ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG might not make any difference: separate enforcing of lack of optimization. But just to see what results I've done "pkg delete llvm40" and am doing another build with ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG= and its supporting code in place in addition to using WITH_DEBUG= as the type of build fro FreeBSD's viewpoint. If you know that the test is a waste of machine cycles, you can let me know if you want. === Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Mar 30 20:54:21 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 6D6CED26990 for ; Thu, 30 Mar 2017 20:54:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-14.reflexion.net [208.70.210.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1E14912B2 for ; Thu, 30 Mar 2017 20:54:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22391 invoked from network); 30 Mar 2017 20:57:03 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Mar 2017 20:57:03 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Thu, 30 Mar 2017 16:54:19 -0400 (EDT) Received: (qmail 23200 invoked from network); 30 Mar 2017 20:54:19 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Mar 2017 20:54:19 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 71EAFEC8675; Thu, 30 Mar 2017 13:54:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: <20170330175519.GA34411@spindle.one-eyed-alien.net> Date: Thu, 30 Mar 2017 13:54:17 -0700 Cc: Dimitry Andric , FreeBSD Current , FreeBSD Toolchain , FreeBSD Ports , Johannes M Dieterich , Matthew Rezny , FreeBSD PowerPC ML Content-Transfer-Encoding: 7bit Message-Id: References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> <20170330175519.GA34411@spindle.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.3273) 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: Thu, 30 Mar 2017 20:54:21 -0000 On 2017-Mar-30, at 10:55 AM, Brooks Davis wrote: > 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. Yep. It fights with time preferences as well: when I tried building gcc6 "full bootstrap" via poudriere cross- builds on amd64 (4 cores/threads used) and native on a bpim3 (-mcpu=cortex-a7 with 4 cores supported by FreeBSD and 2GB if RAM) the native build was much faster as I remember. Of course once the cross build was using the gcc6 internal bootstrap compiler not much was running native cross-toolchain materials. (Building that internal bootstrap compiler did have a native-clang cross-compiler involved.) [I do not have access to server-class thread counts or RAM either. And the non-multithread stages contribute even in those contexts as well.] So I'm not looking forward to the issue from that point of view. === Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Mar 30 21:04:23 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 D869BD26E9C; Thu, 30 Mar 2017 21:04:23 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F8011A7D; Thu, 30 Mar 2017 21:04:23 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::6071:fd3d:eb67:3bb1] (unknown [IPv6:2001:470:7a58:0:6071:fd3d:eb67:3bb1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A3B98150F0; Thu, 30 Mar 2017 23:04:20 +0200 (CEST) From: Dimitry Andric Message-Id: <7C9A1030-E489-489C-A17B-4981DE429FEA@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_592CEB00-EFD3-48EB-AA9E-58C9F49FC2FF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) Date: Thu, 30 Mar 2017 23:04:15 +0200 In-Reply-To: <20170330175519.GA34411@spindle.one-eyed-alien.net> Cc: Alexey Dokuchaev , FreeBSD Current , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Ports , Johannes M Dieterich , Matthew Rezny To: Brooks Davis References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> <20170330175519.GA34411@spindle.one-eyed-alien.net> X-Mailer: Apple Mail (2.3273) 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: Thu, 30 Mar 2017 21:04:24 -0000 --Apple-Mail=_592CEB00-EFD3-48EB-AA9E-58C9F49FC2FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 30 Mar 2017, at 19:55, Brooks Davis wrote: >=20 > On Thu, Mar 30, 2017 at 07:26:19PM +0200, Dimitry Andric wrote: ... >>=20 >> 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. >=20 > I'm looking into improving WITH_DEBUG. I stole the following method from graphics/darktable: Index: devel/llvm40/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- devel/llvm40/Makefile (revision 436685) +++ devel/llvm40/Makefile (working copy) @@ -236,6 +236,11 @@ NOT_FOR_ARCH=3D ia64 .include +.if defined(WITH_DEBUG) +CMAKE_BUILD_TYPE=3D RelWithDebInfo +STRIP=3D +.endif + _CRTLIBDIR=3D = ${LLVM_PREFIX:S|${PREFIX}/||}/lib/clang/${LLVM_RELEASE}/lib/freebsd .if ${ARCH} =3D=3D "amd64" _COMPILER_RT_LIBS=3D \ 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 --Apple-Mail=_592CEB00-EFD3-48EB-AA9E-58C9F49FC2FF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljdctQACgkQsF6jCi4glqOAPACg7xTJA7vHB7TjgbXTSEJIZWYZ IncAoIDyrx2mNKWkPlV8Xathqx4p1FY9 =4mOQ -----END PGP SIGNATURE----- --Apple-Mail=_592CEB00-EFD3-48EB-AA9E-58C9F49FC2FF-- From owner-freebsd-toolchain@freebsd.org Fri Mar 31 02:51:48 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 9DF55D231C1 for ; Fri, 31 Mar 2017 02:51:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61EF8BB9 for ; Fri, 31 Mar 2017 02:51:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8189 invoked from network); 31 Mar 2017 02:51:46 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 31 Mar 2017 02:51:46 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Thu, 30 Mar 2017 22:51:46 -0400 (EDT) Received: (qmail 26095 invoked from network); 31 Mar 2017 02:51:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 31 Mar 2017 02:51:46 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 62F64EC78CC; Thu, 30 Mar 2017 19:51:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: Date: Thu, 30 Mar 2017 19:51:44 -0700 Cc: FreeBSD Ports , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> <20170329155316.GK59667@spindle.one-eyed-alien.net> To: Brooks Davis , Dimitry Andric X-Mailer: Apple Mail (2.3273) 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: Fri, 31 Mar 2017 02:51:48 -0000 On 2017-Mar-30, at 1:22 PM, Mark Millard wrote: > On 2017-Mar-29, at 8:53 AM, Brooks Davis wrote: > >> On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote: >>> On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: >>> >>>> On 26 Mar 2017, at 23:36, Mark Millard wrote: >>>>> >>>>> I upgraded from llvm40 r4 to final. An interesting result was >>>>> its creation of a backup package for llvm40-4.0.0.r4: >>>>> >>>>> about 13 cpu-core-hours running pkg create >>>>> >>>>> (Remember: I've been building with WITH_DEBUG= ) Its >>>>> single-threaded status stands out via elapsed time >>>>> approximately matching. >>>>> >>>>> I'll note that it was somewhat under 6 elapsed hours for >>>>> staging to have been populated (-j4 with 4 cores present >>>>> helps for this part). >>>>> >>>>> (Of course these elapsed-time figures are rather system >>>>> dependent, although the ratio might be more stable.) >>>>> >>>>> >>>>> >>>>> Also interesting was: >>>>> >>>>> Installed packages to be REMOVED: >>>>> llvm40-4.0.0.r4 >>>>> >>>>> Number of packages to be removed: 1 >>>>> >>>>> The operation will free 49 GiB. >>>> >>>> Yes, this is big. But there is no real need to build the llvm ports >>>> with debug information, unless you want to hack on llvm itself. And >>>> in that case, you are better served by a Subversion checkout or Git >>>> clone from upstream instead. >>>> >>>> -Dimitry >>> >>> FYI: >>> >>> Historically unless something extreme like this ends up >>> involved I build everything using WITH_DEBUG= or explicit >>> -g's in order to have better information on any failure. >>> >>> This is extreme enough that next time I synchronize >>> /usr/ports and it has a devel/llvm40 update I'll >>> likely rebuild devel/llvm40 without using WITH_DEBUG= . >>> I'm more concerned with the time it takes than with >>> the file system space involved. >> >> In the case of LLVM, enabling debug builds does a LOT more than adding >> symbols. It's much more like enabling WITNESS and INVARIANTS in your >> kernel, except that the performance of the resulting binary is much >> worse than a WITNESS kernel (more like 10x slowdown). >> >> As Dimitry points out, these builds are of questionable value in ports >> so garbage collecting the knob might be the sensable thing to do. > > Sounds like the ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG technique > would not change the "WITNESS and INVARIANTS"-like part of the > issue. In fact if WITH_DEBUG= causes the cmake debug-style > llvm40 build ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG might not > make any difference: separate enforcing of lack of optimization. > > But just to see what results I've done "pkg delete llvm40" > and am doing another build with ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG= > and its supporting code in place in addition to using WITH_DEBUG= > as the type of build fro FreeBSD's viewpoint. > > If you know that the test is a waste of machine cycles, you can > let me know if you want. The experiment showed that ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG use made no difference for devel/llvm40 so devel/llvm40 itself has to change such as what Dimitry Andric reported separately as a working change to the Makefile . (ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG would still have its uses for various other ports.) === Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Mar 31 23:52:04 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 3F1C4D27F6A for ; Fri, 31 Mar 2017 23:52:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-77.reflexion.net [208.70.210.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F36A6E9C for ; Fri, 31 Mar 2017 23:52:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15851 invoked from network); 31 Mar 2017 23:52:01 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 31 Mar 2017 23:52:01 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Fri, 31 Mar 2017 19:52:01 -0400 (EDT) Received: (qmail 11760 invoked from network); 31 Mar 2017 23:52:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 31 Mar 2017 23:52:01 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 718D4EC8FE4; Fri, 31 Mar 2017 16:52:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: Date: Fri, 31 Mar 2017 16:51:59 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> <20170329155316.GK59667@spindle.one-eyed-alien.net> To: Brooks Davis , Dimitry Andric , FreeBSD Ports X-Mailer: Apple Mail (2.3273) 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: Fri, 31 Mar 2017 23:52:04 -0000 On 2017-Mar-30, at 7:51 PM, Mark Millard wrote: > On 2017-Mar-30, at 1:22 PM, Mark Millard wrote: >=20 >> Sounds like the ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG technique >> would not change the "WITNESS and INVARIANTS"-like part of the >> issue. In fact if WITH_DEBUG=3D causes the cmake debug-style >> llvm40 build ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG might not >> make any difference: separate enforcing of lack of optimization. >>=20 >> But just to see what results I've done "pkg delete llvm40" >> and am doing another build with ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=3D >> and its supporting code in place in addition to using WITH_DEBUG=3D >> as the type of build fro FreeBSD's viewpoint. >>=20 >> If you know that the test is a waste of machine cycles, you can >> let me know if you want. >=20 > The experiment showed that ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG > use made no difference for devel/llvm40 so devel/llvm40 itself > has to change such as what Dimitry Andric reported separately > as a working change to the Makefile . >=20 > (ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG would still have its uses > for various other ports.) I've now tried with both ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG and: # svnlite diff /usr/ports/devel/llvm40/ Index: /usr/ports/devel/llvm40/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/ports/devel/llvm40/Makefile (revision 436747) +++ /usr/ports/devel/llvm40/Makefile (working copy) @@ -236,6 +236,11 @@ =20 .include =20 +.if defined(WITH_DEBUG) +CMAKE_BUILD_TYPE=3D RelWithDebInfo +STRIP=3D +.endif + _CRTLIBDIR=3D = ${LLVM_PREFIX:S|${PREFIX}/||}/lib/clang/${LLVM_RELEASE}/lib/freebsd .if ${ARCH} =3D=3D "amd64" _COMPILER_RT_LIBS=3D \ pkg delete after the build reports: Installed packages to be REMOVED: llvm40-4.0.0 Number of packages to be removed: 1 The operation will free 42 GiB. So down by 7 GiBytes from 49 GiBytes. (I did not actually delete it.) Also: # du -sg /usr/obj/portswork/usr/ports/devel/llvm40 102 /usr/obj/portswork/usr/ports/devel/llvm40 which is down by 16 GiBytes from 118 GiBytes. Reminder: These are from portmaster -DK so no cleanup after the build, which is what leaves the source code and such around in case of needing to look at a problem. (102+42) GiBytes =3D=3D 146 GiBytes. vs. (118+49) GiBytes =3D=3D 167 GiBytes. So a difference of 21 GiBytes (or so). But that is for everything in each case (and WITH_DEBUG=3D in use): # more /var/db/ports/devel_llvm40/options # This file is auto-generated by 'make config'. # Options for llvm40-4.0.0.r4 _OPTIONS_READ=3Dllvm40-4.0.0.r4 _FILE_COMPLETE_OPTIONS_LIST=3DCLANG DOCS EXTRAS LIT LLD LLDB OPTIONS_FILE_SET+=3DCLANG OPTIONS_FILE_SET+=3DDOCS OPTIONS_FILE_SET+=3DEXTRAS OPTIONS_FILE_SET+=3DLIT OPTIONS_FILE_SET+=3DLLD OPTIONS_FILE_SET+=3DLLDB So avoiding WITH_DEBUG=3D and/or various build options is still the major way of avoiding use of lots of space if it is an issue. Why no RAM+SWAP total report this time: As far as I know FreeBSD does not track or report peak swap-space usage since the last boot. And, unfortunately I was not around to just sit and watch a top display this time and I did not set up any periodic recording into a file. That is why I've not reported on the RAM+SWAP total this time. It will have to be another experiment some other time. [I do wish FreeBSD had a way of reporting peak swap-space usage.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Apr 1 10:51:14 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 80518D2915D for ; Sat, 1 Apr 2017 10:51:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-78.reflexion.net [208.70.210.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 353C831E for ; Sat, 1 Apr 2017 10:51:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25224 invoked from network); 1 Apr 2017 10:52:08 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 1 Apr 2017 10:52:08 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 01 Apr 2017 06:51:11 -0400 (EDT) Received: (qmail 23165 invoked from network); 1 Apr 2017 10:51:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 1 Apr 2017 10:51:11 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 97D6FEC8630; Sat, 1 Apr 2017 03:51:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) From: Mark Millard In-Reply-To: Date: Sat, 1 Apr 2017 03:51:10 -0700 Cc: FreeBSD Current , FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <39C60316-F905-490D-B0AB-BC24D7F351A2@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <45E32F4F-A238-47AA-8E1E-7AD4D9E857D9@dsl-only.net> <20170329155316.GK59667@spindle.one-eyed-alien.net> To: Brooks Davis , Dimitry Andric , FreeBSD Ports X-Mailer: Apple Mail (2.3273) 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: Sat, 01 Apr 2017 10:51:14 -0000 On 2017-Mar-31, at 4:51 PM, Mark Millard wrote: > On 2017-Mar-30, at 7:51 PM, Mark Millard = wrote: >=20 >> On 2017-Mar-30, at 1:22 PM, Mark Millard = wrote: >>=20 >>> Sounds like the ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG technique >>> would not change the "WITNESS and INVARIANTS"-like part of the >>> issue. In fact if WITH_DEBUG=3D causes the cmake debug-style >>> llvm40 build ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG might not >>> make any difference: separate enforcing of lack of optimization. >>>=20 >>> But just to see what results I've done "pkg delete llvm40" >>> and am doing another build with ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=3D >>> and its supporting code in place in addition to using WITH_DEBUG=3D >>> as the type of build fro FreeBSD's viewpoint. >>>=20 >>> If you know that the test is a waste of machine cycles, you can >>> let me know if you want. >>=20 >> The experiment showed that ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG >> use made no difference for devel/llvm40 so devel/llvm40 itself >> has to change such as what Dimitry Andric reported separately >> as a working change to the Makefile . >>=20 >> (ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG would still have its uses >> for various other ports.) >=20 > I've now tried with both ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG and: I may have had a textual error that prevented ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG from even potentially contributing. So I'll re-run this test. For now I presume that what I reported was okay and so I continue to refer to these figures later below. > # svnlite diff /usr/ports/devel/llvm40/ > Index: /usr/ports/devel/llvm40/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/ports/devel/llvm40/Makefile (revision 436747) > +++ /usr/ports/devel/llvm40/Makefile (working copy) > @@ -236,6 +236,11 @@ >=20 > .include >=20 > +.if defined(WITH_DEBUG) > +CMAKE_BUILD_TYPE=3D RelWithDebInfo > +STRIP=3D > +.endif > + > _CRTLIBDIR=3D = ${LLVM_PREFIX:S|${PREFIX}/||}/lib/clang/${LLVM_RELEASE}/lib/freebsd > .if ${ARCH} =3D=3D "amd64" > _COMPILER_RT_LIBS=3D \ >=20 >=20 >=20 > pkg delete after the build reports: >=20 > Installed packages to be REMOVED: > llvm40-4.0.0 >=20 > Number of packages to be removed: 1 >=20 > The operation will free 42 GiB. >=20 > So down by 7 GiBytes from 49 GiBytes. >=20 > (I did not actually delete it.) >=20 > Also: >=20 > # du -sg /usr/obj/portswork/usr/ports/devel/llvm40 > 102 /usr/obj/portswork/usr/ports/devel/llvm40 >=20 > which is down by 16 GiBytes from 118 GiBytes. >=20 > Reminder: These are from portmaster -DK so no > cleanup after the build, which is what leaves > the source code and such around in case of > needing to look at a problem. >=20 > (102+42) GiBytes =3D=3D 146 GiBytes. > vs. > (118+49) GiBytes =3D=3D 167 GiBytes. >=20 > So a difference of 21 GiBytes (or so). >=20 > But that is for everything in each case (and > WITH_DEBUG=3D in use): >=20 > # more /var/db/ports/devel_llvm40/options > # This file is auto-generated by 'make config'. > # Options for llvm40-4.0.0.r4 > _OPTIONS_READ=3Dllvm40-4.0.0.r4 > _FILE_COMPLETE_OPTIONS_LIST=3DCLANG DOCS EXTRAS LIT LLD LLDB > OPTIONS_FILE_SET+=3DCLANG > OPTIONS_FILE_SET+=3DDOCS > OPTIONS_FILE_SET+=3DEXTRAS > OPTIONS_FILE_SET+=3DLIT > OPTIONS_FILE_SET+=3DLLD > OPTIONS_FILE_SET+=3DLLDB >=20 > So avoiding WITH_DEBUG=3D and/or various build options > is still the major way of avoiding use of lots of space > if it is an issue. >=20 >=20 >=20 > Why no RAM+SWAP total report this time: >=20 > As far as I know FreeBSD does not track or report peak > swap-space usage since the last boot. And, unfortunately > I was not around to just sit and watch a top display this > time and I did not set up any periodic recording into a > file. >=20 > That is why I've not reported on the RAM+SWAP total > this time. It will have to be another experiment > some other time. >=20 > [I do wish FreeBSD had a way of reporting peak swap-space > usage.] I've also tried without WITH_DEBUG=3D 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. Proceed with deinstalling packages? [y/N]: n # du -sg /usr/obj/portswork/usr/ports/devel/llvm40/ 5 /usr/obj/portswork/usr/ports/devel/llvm40/ So the alternatives (with everything built each time): (5+1) GiBytes =3D=3D 6 GiBytes. (without WITH_DEBUG=3D) vs. (102+42) GiBytes =3D=3D 146 GiBytes. (WITH_DEBUG=3D but the adjusted = llvm40/Makefiele) vs. (118+49) GiBytes =3D=3D 167 GiBytes. (WITH_DEBUG=3D with Makefile = adjustment) I'll likely end up having /etc/make.conf contain something like the following for most or all of my FreeBSD environments: # # =46rom a local /usr/ports/Mk/bsd.port.mk extension: ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=3D # .if ${.CURDIR:M*/devel/llvm*} #WITH_DEBUG=3D .else WITH_DEBUG=3D .endif WITH_DEBUG_FILES=3D Along with using: # svnlite diff /usr/ports/Mk/ Index: /usr/ports/Mk/bsd.port.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/ports/Mk/bsd.port.mk (revision 436747) +++ /usr/ports/Mk/bsd.port.mk (working copy) @@ -1646,7 +1646,11 @@ STRIP_CMD=3D ${TRUE} .endif DEBUG_FLAGS?=3D -g +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG) +CFLAGS:=3D ${CFLAGS} ${DEBUG_FLAGS} +.else CFLAGS:=3D ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} +.endif .if defined(INSTALL_TARGET) INSTALL_TARGET:=3D ${INSTALL_TARGET:S/^install-strip$/install/g} .endif [Although apparently the ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG use has no effect for devel/llvm40 .] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Apr 1 11:57:28 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 BC719D29907 for ; Sat, 1 Apr 2017 11:57:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ABB4ECF for ; Sat, 1 Apr 2017 11:57:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v31BvSsG000897 for ; Sat, 1 Apr 2017 11:57:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216707] exp-run: Update lang/gcc from GCC 4.9 to GCC 5 Date: Sat, 01 Apr 2017 11:57:28 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Ports Framework X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: portmgr@FreeBSD.org X-Bugzilla-Flags: exp-run? merge-quarterly? X-Bugzilla-Changed-Fields: flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sat, 01 Apr 2017 11:57:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216707 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |merge-quarterly? --- Comment #44 from Jan Beich --- Can you merge this to 2017Q2? I'd prefer to not worry stuff builds on 4.9.x when doing MFH for security updates. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Apr 1 13:23:51 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 38F01D27159 for ; Sat, 1 Apr 2017 13:23:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 216A6E92 for ; Sat, 1 Apr 2017 13:23:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v31DNn5W066789 for ; Sat, 1 Apr 2017 13:23:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216707] exp-run: Update lang/gcc from GCC 4.9 to GCC 5 Date: Sat, 01 Apr 2017 13:23:50 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Ports Framework X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: gerald@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: portmgr@FreeBSD.org X-Bugzilla-Flags: exp-run? merge-quarterly? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sat, 01 Apr 2017 13:23:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216707 --- Comment #45 from Gerald Pfeifer --- (In reply to Antoine Brodin from comment #40) > Do not forget to copy files/patch-libc++ from gcc5 to fix the build > with libc++ 4.0, and maybe the patch for aarch64 support too. Yep, files/patch-libc++ has been in my local tree for two months (exactly two months). :-) As for aarch64, I plan on taking care of that very quickly after the original commit. (It's not a regression, but will be a nice addition.) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Apr 1 14:26:34 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 9FD89D2856A for ; Sat, 1 Apr 2017 14:26:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84ADCEBE for ; Sat, 1 Apr 2017 14:26:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v31EQY4M017736 for ; Sat, 1 Apr 2017 14:26:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 218164] lang/gcc5: Bootstrap comparison failure Date: Sat, 01 Apr 2017 14:26:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: gerald@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sat, 01 Apr 2017 14:26:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218164 Gerald Pfeifer changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|gerald@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg Flags|maintainer-feedback?(gerald | |@FreeBSD.org) | --- Comment #3 from Gerald Pfeifer --- (In reply to Micha=C5=82 "phoe" Herda from comment #2) > I can build both gcc5 and gcc48 as long as I do not select bootstrapping= =20 > in config. If anything, it's actually supposed to be the other way around, boostrapping should be the safer option. The error you see is GCC compiling itself repeatedly does not lead to a consistent result as it should. Clearly this does not happen for other SPARC targets of GCC, and I'm afraid I won't be able to help with this. (Luckily there is at least a workaround of disabling bootstrap, which is the default for lang/gcc.) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Apr 1 15:04:12 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 E67EFD28FEC for ; Sat, 1 Apr 2017 15:04:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D555515A for ; Sat, 1 Apr 2017 15:04:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v31F4C9n016828 for ; Sat, 1 Apr 2017 15:04:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216707] exp-run: Update lang/gcc from GCC 4.9 to GCC 5 Date: Sat, 01 Apr 2017 15:04:12 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Ports Framework X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: portmgr@FreeBSD.org X-Bugzilla-Flags: exp-run? merge-quarterly? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sat, 01 Apr 2017 15:04:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216707 --- Comment #46 from commit-hook@freebsd.org --- A commit references this bug: Author: gerald Date: Sat Apr 1 15:03:22 UTC 2017 New revision: 437437 URL: https://svnweb.freebsd.org/changeset/ports/437437 Log: Update lang/gcc and hence the default version of GCC in the Ports Collection (requested by USE_GCC=3Dyes and various USES=3Dcompiler invocations) from GCC 4.9.4 to GCC 5.4. files/patch-arm-support and files/patch-gcc_system.h have become obsolete. New patches files/patch-arm-unwind-cxx-support and files/patch-libc++ help support arm targets and new libc++ in base. ONLY_FOR_ARCHS now also includes arm. A new option GRAPHITE_DESC, off by default for now, adds support for Graphite loop optimizations. Finally, conflicts with other lang/gcc* ports are adjusted suitably. In terms of changes for users, this upgrade brings the following: The default mode for C is now -std=3Dgnu11 instead of -std=3Dgnu89. New warning options -Wc90-c99-compat and -Wc99-c11-compat may prove useful on that front. The C++ front end now has full C++14 language support including C++14 variable templates, C++14 aggregates with non-static data member initializers, C++14 extended constexpr, and more. The Standard C++ Library (libstdc++) has full C++11 support and experimental full C++14 support. It uses a new ABI by default. There have been significant improvements to inter-procedural optimizations and link-time optimization such as One Definition Rule based merging of C= ++ types as well as register allocation. OpenMP 4.0 specification offloading features are now supported by the C, C++, and Fortran compilers. Cilk Plus, an extension to the C and C++ languages to support data and task parallelism, has been added as well. New warning options -Wswitch-bool, -Wlogical-not-parentheses, -Wbool-compare and -Wsizeof-array-argument may prove useful as may new preprocessor directives __has_include, __has_include_next, and __has_attribute. GCC can now be built as a shared library for embedding in other processes (such as interpreters), suitable for Just-In-Time compilation to machine code. This provides a C API and a C++ wrapper API. Many code generation improvements for AArch64, ARM, support for AVX-512{BW,DQ,VL,IFMA,VBMI} and Intel MPX on x86-64, and generally improvements on many targets. The Local Register Allocator (LRA) now contains a rematerialization subpass and is able to reuse the PIC hard register on x86/x86-64 to improve performance of position independent code. https://gcc.gnu.org/gcc-5/changes.html has a more extensive set of changes and https://gcc.gnu.org/gcc-5/porting_to.html has a solid overview of issue you may encountering porting to this new version. PR: 216707, 218125 Tested by: antoine (-exp runs) Supported by: jbeich, tcberner, and others Changes: head/Mk/bsd.default-versions.mk head/lang/gcc/Makefile head/lang/gcc/distinfo head/lang/gcc/files/patch-arm-support head/lang/gcc/files/patch-arm-unwind-cxx-support head/lang/gcc/files/patch-gcc_system.h head/lang/gcc/files/patch-libc++ head/lang/gcc/pkg-descr head/lang/gcc/pkg-plist head/lang/gcc49/Makefile head/lang/gcc5/Makefile head/lang/gcc5-devel/Makefile --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Apr 1 15:06:22 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 89A97D29146 for ; Sat, 1 Apr 2017 15:06:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78F52688 for ; Sat, 1 Apr 2017 15:06:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v31F6LeR086698 for ; Sat, 1 Apr 2017 15:06:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216707] exp-run: Update lang/gcc from GCC 4.9 to GCC 5 Date: Sat, 01 Apr 2017 15:06:22 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Ports Framework X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: gerald@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: portmgr@FreeBSD.org X-Bugzilla-Flags: merge-quarterly+ X-Bugzilla-Changed-Fields: flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sat, 01 Apr 2017 15:06:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216707 Gerald Pfeifer changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|exp-run?, merge-quarterly? |merge-quarterly+ --- Comment #47 from Gerald Pfeifer --- No objections including this in the quarterly branch, though given the large number of dependent ports (cf. the next commit) may this be a little intrusive/risky?=20=20 I am not planning to do this myself, though; if for no other reason, then shortage of time. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Apr 1 15:24:33 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 4EC18D2968F for ; Sat, 1 Apr 2017 15:24:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3CB2A12D for ; Sat, 1 Apr 2017 15:24:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v31FOWMJ066437 for ; Sat, 1 Apr 2017 15:24:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216707] exp-run: Update lang/gcc from GCC 4.9 to GCC 5 Date: Sat, 01 Apr 2017 15:24:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Ports Framework X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: portmgr@FreeBSD.org X-Bugzilla-Flags: merge-quarterly+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sat, 01 Apr 2017 15:24:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216707 --- Comment #48 from commit-hook@freebsd.org --- A commit references this bug: Author: gerald Date: Sat Apr 1 15:23:43 UTC 2017 New revision: 437439 URL: https://svnweb.freebsd.org/changeset/ports/437439 Log: Bump PORTREVISIONs for ports depending on the canonical version of GCC and lang/gcc which have moved from GCC 4.9.4 to GCC 5.4 (at least under some circumstances such as versions of FreeBSD or platforms). This includes ports - with USE_GCC=3Dyes or USE_GCC=3Dany, - with USES=3Dfortran, - using using Mk/bsd.octave.mk which in turn has USES=3Dfortran, and - with USES=3Dcompiler specifying openmp, nestedfct, c++11-lib, c++14-la= ng, c++11-lang, c++0x, c11, or gcc-c++11-lib. PR: 216707 Changes: head/archivers/kf5-karchive/Makefile head/archivers/paq/Makefile head/archivers/pxz/Makefile head/archivers/py-brotli/Makefile head/archivers/rvm/Makefile head/astro/geographiclib/Makefile head/astro/gpstk/Makefile head/astro/kstars/Makefile head/astro/libosmium/Makefile head/astro/nightfall/Makefile head/astro/opencpn/Makefile head/astro/qmapshack/Makefile head/astro/viking/Makefile head/astro/wcslib/Makefile head/astro/xtide/Makefile head/audio/audacity/Makefile head/audio/calf/Makefile head/audio/ccaudio2/Makefile head/audio/chromaprint/Makefile head/audio/codec2/Makefile head/audio/csound/Makefile head/audio/csound6/Makefile head/audio/deadbeef/Makefile head/audio/espeak/Makefile head/audio/firefly/Makefile head/audio/funktrackergold/Makefile head/audio/gbsplay/Makefile head/audio/gnuspeechsa/Makefile head/audio/gogglesmm/Makefile head/audio/idjc/Makefile head/audio/libsoxr/Makefile head/audio/murmur/Makefile head/audio/musescore/Makefile head/audio/musicpd/Makefile head/audio/ncmpcpp/Makefile head/audio/openal-soft/Makefile head/audio/openspc/Makefile head/audio/pragha/Makefile head/audio/pulseaudio/Makefile head/audio/py-karaoke/Makefile head/audio/py-tagpy/Makefile head/audio/qjackctl/Makefile head/audio/rosegarden/Makefile head/audio/sayonara/Makefile head/audio/schism/Makefile head/audio/smasher/Makefile head/audio/soundkonverter/Makefile head/audio/soundtouch/Makefile head/audio/spek/Makefile head/audio/tomahawk/Makefile head/audio/wxguitar/Makefile head/audio/xmms-gbsplay/Makefile head/benchmarks/himenobench/Makefile head/benchmarks/hpl/Makefile head/benchmarks/octave-forge-benchmark/Makefile head/benchmarks/phoronix-test-suite/Makefile head/benchmarks/polygraph/Makefile head/biology/bowtie/Makefile head/biology/cd-hit/Makefile head/biology/crux/Makefile head/biology/diamond/Makefile head/biology/fasttree/Makefile head/biology/jellyfish/Makefile head/biology/molden/Makefile head/biology/mopac/Makefile head/biology/ncbi-blast+/Makefile head/biology/plink/Makefile head/biology/psi88/Makefile head/biology/seqan-apps/Makefile head/biology/seqtools/Makefile head/biology/ssaha/Makefile head/biology/t_coffee/Makefile head/biology/tinker/Makefile head/cad/NASTRAN-95/Makefile head/cad/alliance/Makefile head/cad/calculix/Makefile head/cad/cura-engine/Makefile head/cad/elmerfem/Makefile head/cad/feappv/Makefile head/cad/freecad/Makefile head/cad/freehdl/Makefile head/cad/gmsh/Makefile head/cad/gspiceui/Makefile head/cad/kicad/Makefile head/cad/kicad-devel/Makefile head/cad/klayout/Makefile head/cad/libopencad/Makefile head/cad/librecad/Makefile head/cad/meshlab/Makefile head/cad/opencascade/Makefile head/cad/openscad/Makefile head/cad/openvsp/Makefile head/cad/pdnmesh/Makefile head/cad/qelectrotech/Makefile head/cad/sceptre/Makefile head/cad/scotch/Makefile head/cad/stepcode/Makefile head/cad/tochnog/Makefile head/chinese/ibus-libpinyin/Makefile head/chinese/ibus-pinyin/Makefile head/chinese/librime/Makefile head/chinese/opencc/Makefile head/chinese/pyzy/Makefile head/comms/aldo/Makefile head/comms/dabstick-radio/Makefile head/comms/efax-gtk/Makefile head/comms/ems-flasher/Makefile head/comms/fldigi/Makefile head/comms/freedv/Makefile head/comms/gnuradio/Makefile head/comms/gr-osmosdr/Makefile head/comms/qt5-serialbus/Makefile head/comms/sdr-wspr/Makefile head/comms/telldus-core/Makefile head/comms/trustedqsl/Makefile head/comms/uhd/Makefile head/comms/usrp/Makefile head/comms/wsjt/Makefile head/comms/wsjtx/Makefile head/comms/wspr/Makefile head/converters/pdf2djvu/Makefile head/databases/clickhouse/Makefile head/databases/evolution-data-server/Makefile head/databases/fastdb/Makefile head/databases/galera/Makefile head/databases/gigabase/Makefile head/databases/gnats4/Makefile head/databases/gomdb/Makefile head/databases/grass/Makefile head/databases/leveldb/Makefile head/databases/levigo/Makefile head/databases/mariadb-connector-c/Makefile head/databases/mariadb100-server/Makefile head/databases/mariadb101-server/Makefile head/databases/mariadb55-server/Makefile head/databases/mysql-q4m/Makefile head/databases/mysql56-server/Makefile head/databases/mysql57-server/Makefile head/databases/mysql80-server/Makefile head/databases/percona57-server/Makefile head/databases/pgadmin3/Makefile head/databases/pgmodeler/Makefile head/databases/pgrouting/Makefile head/databases/php5-pdo_cassandra/Makefile head/databases/postgresql-plv8js/Makefile head/databases/riak2/Makefile head/databases/rocksdb/Makefile head/databases/sqlitestudio/Makefile head/databases/tarantool/Makefile head/databases/vsqlite/Makefile head/deskutils/bijiben/Makefile head/deskutils/gnome-documents/Makefile head/deskutils/gnome-initial-setup/Makefile head/deskutils/gnome-photos/Makefile head/deskutils/gnome-todo/Makefile head/deskutils/gnote/Makefile head/deskutils/growl-for-linux/Makefile head/deskutils/homerun/Makefile head/deskutils/kdeconnect/Makefile head/deskutils/owncloudclient/Makefile head/deskutils/sliderule/Makefile head/deskutils/taskd/Makefile head/deskutils/taskwarrior/Makefile head/deskutils/treesheets/Makefile head/deskutils/xneur/Makefile head/devel/aegis/Makefile head/devel/android-tools-adb/Makefile head/devel/android-tools-fastboot/Makefile head/devel/android-tools-simpleperf/Makefile head/devel/api-sanity-autotest/Makefile head/devel/argdata/Makefile head/devel/asmutils/Makefile head/devel/atlas-devel/Makefile head/devel/aws-sdk-cpp/Makefile head/devel/bisoncpp/Makefile head/devel/bossa/Makefile head/devel/bullet/Makefile head/devel/caf/Makefile head/devel/ccrtp/Makefile head/devel/cctz/Makefile head/devel/cheritrace-devel/Makefile head/devel/clanlib/Makefile head/devel/covtool/Makefile head/devel/cppcheck/Makefile head/devel/cssc/Makefile head/devel/cx_Freeze/Makefile head/devel/dbus-c++/Makefile head/devel/devhelp/Makefile head/devel/dia2code+/Makefile head/devel/drpython/Makefile head/devel/efivar/Makefile head/devel/efl/Makefile head/devel/embb/Makefile head/devel/eris/Makefile head/devel/flatbuffers/Makefile head/devel/freeocl/Makefile head/devel/gdb66/Makefile head/devel/gitg/Makefile head/devel/gnu-efi/Makefile head/devel/godot/Makefile head/devel/grantlee5/Makefile head/devel/hhdate/Makefile head/devel/hyperscan/Makefile head/devel/injeqt/Makefile head/devel/ipython/Makefile head/devel/jsoncpp/Makefile head/devel/jsonnet/Makefile head/devel/kBuild/Makefile head/devel/kdesvn-kde4/Makefile head/devel/kdevelop-kde4/Makefile head/devel/kdevelop-pg-qt/Makefile head/devel/kdevelop-php/Makefile head/devel/kdevelop-php-docs/Makefile head/devel/kdevplatform/Makefile head/devel/kf5-kauth/Makefile head/devel/kf5-kbookmarks/Makefile head/devel/kf5-kcmutils/Makefile head/devel/kf5-kconfig/Makefile head/devel/kf5-kcoreaddons/Makefile head/devel/kf5-kcrash/Makefile head/devel/kf5-kdbusaddons/Makefile head/devel/kf5-kdeclarative/Makefile head/devel/kf5-kdoctools/Makefile head/devel/kf5-kfilemetadata/Makefile head/devel/kf5-ki18n/Makefile head/devel/kf5-kidletime/Makefile head/devel/kf5-kio/Makefile head/devel/kf5-kitemmodels/Makefile head/devel/kf5-knewstuff/Makefile head/devel/kf5-knotifications/Makefile head/devel/kf5-knotifyconfig/Makefile head/devel/kf5-kpackage/Makefile head/devel/kf5-kparts/Makefile head/devel/kf5-kpeople/Makefile head/devel/kf5-kpty/Makefile head/devel/kf5-kservice/Makefile head/devel/kf5-ktexteditor/Makefile head/devel/kf5-kunitconversion/Makefile head/devel/kf5-solid/Makefile head/devel/kf5-threadweaver/Makefile head/devel/libbobcat/Makefile head/devel/libbrotli/Makefile head/devel/libconcurrent/Makefile head/devel/libcrossguid/Makefile head/devel/libdbusmenu-qt/Makefile head/devel/libflatarray/Makefile head/devel/libfmt/Makefile head/devel/libgit2-glib/Makefile head/devel/libgrading/Makefile head/devel/libical-glib/Makefile head/devel/liblas/Makefile head/devel/liblouisxml/Makefile head/devel/liblxqt/Makefile head/devel/libopkele/Makefile head/devel/liborcus/Makefile head/devel/libqtxdg/Makefile head/devel/libtuntap/Makefile head/devel/libwfut/Makefile head/devel/lldb38/Makefile head/devel/llvm-cheri/Makefile head/devel/llvm-devel/Makefile head/devel/llvm34/Makefile head/devel/llvm35/Makefile head/devel/llvm36/Makefile head/devel/llvm38/Makefile head/devel/llvm39/Makefile head/devel/llvm40/Makefile head/devel/lockfree-malloc/Makefile head/devel/love/Makefile head/devel/mercator/Makefile head/devel/msgpack/Makefile head/devel/msp430-debug-stack/Makefile head/devel/nlohmann-json/Makefile head/devel/ocaml-lacaml/Makefile head/devel/opendht/Makefile head/devel/openmp/Makefile head/devel/p5-perlkde/Makefile head/devel/papi/Makefile head/devel/ponscripter-sekai/Makefile head/devel/protobuf/Makefile head/devel/pure-stllib/Makefile head/devel/pwlib/Makefile head/devel/py-llfuse/Makefile head/devel/py-llvmlite/Makefile head/devel/py-numba/Makefile head/devel/py-tables/Makefile head/devel/qbs/Makefile head/devel/qt5-qmake/Makefile head/devel/qtcreator/Makefile head/devel/raknet/Makefile head/devel/rapidjson/Makefile head/devel/re2/Makefile head/devel/rhtvision/Makefile head/devel/rlvm/Makefile head/devel/sdl2pp/Makefile head/devel/sfml/Makefile head/devel/simgear/Makefile head/devel/smv/Makefile head/devel/sourcenav/Makefile head/devel/thrift-cpp/Makefile head/devel/tigcc/Makefile head/devel/ucommon/Makefile head/devel/valgrind/Makefile head/devel/valgrind-devel/Makefile head/devel/varconf/Makefile head/devel/wxformbuilder/Makefile head/devel/zeal/Makefile head/dns/bundy/Makefile head/dns/c-ares/Makefile head/dns/dnsdist/Makefile head/dns/kf5-kdnssd/Makefile head/dns/powerdns/Makefile head/dns/powerdns-recursor/Makefile head/dns/void-zones-tools/Makefile head/dns/yadifa/Makefile head/editors/calligra/Makefile head/editors/codelite/Makefile head/editors/cooledit/Makefile head/editors/focuswriter/Makefile head/editors/latexila/Makefile head/editors/libreoffice/Makefile head/editors/libreoffice4/Makefile head/editors/openoffice-4/Makefile head/editors/openoffice-devel/Makefile head/editors/p5-Padre/Makefile head/editors/poedit/Makefile head/editors/scite/Makefile head/editors/yzis/Makefile head/editors/zile/Makefile head/emulators/bochs/Makefile head/emulators/catapult/Makefile head/emulators/citra/Makefile head/emulators/dolphin-emu/Makefile head/emulators/fceux/Makefile head/emulators/gxemul/Makefile head/emulators/higan/Makefile head/emulators/mame/Makefile head/emulators/mednafen/Makefile head/emulators/mupen64plus-rsp-cxd4/Makefile head/emulators/openmsx/Makefile head/emulators/pearpc/Makefile head/emulators/pipelight/Makefile head/emulators/ppsspp/Makefile head/emulators/raine/Makefile head/emulators/riscv-isa-sim/Makefile head/emulators/skyeye/Makefile head/emulators/snes9x-gtk/Makefile head/emulators/stella/Makefile head/emulators/wine/Makefile head/emulators/wine-devel/Makefile head/emulators/wxmupen64plus/Makefile head/emulators/x49gp/Makefile head/finance/bitcoin-armory/Makefile head/finance/gnucash/Makefile head/finance/ledger/Makefile head/finance/moneymanagerex/Makefile head/finance/qhacc/Makefile head/finance/skrooge/Makefile head/french/aster/Makefile head/french/eficas/Makefile head/french/med/Makefile head/ftp/filezilla/Makefile head/ftp/libfilezilla/Makefile head/games/0ad/Makefile head/games/3omns/Makefile head/games/adonthell/Makefile head/games/alienarena/Makefile head/games/asc/Makefile head/games/blinkensisters/Makefile head/games/braincurses/Makefile head/games/bzflag/Makefile head/games/cataclysm-dda/Makefile head/games/cockatrice/Makefile head/games/connectagram/Makefile head/games/corsix-th/Makefile head/games/craft/Makefile head/games/criticalmass/Makefile head/games/critterding/Makefile head/games/doomsday/Makefile head/games/dunelegacy/Makefile head/games/dustrac/Makefile head/games/easyrpg-player/Makefile head/games/eduke32/Makefile head/games/el/Makefile head/games/ember/Makefile head/games/emptyepsilon/Makefile head/games/endless-sky/Makefile head/games/etracer/Makefile head/games/exult/Makefile head/games/flightgear/Makefile head/games/freecell-solver/Makefile head/games/freedink-dfarc/Makefile head/games/freeminer/Makefile head/games/gnomebreakout/Makefile head/games/gnubg/Makefile head/games/golly/Makefile head/games/gottet/Makefile head/games/gtkpool/Makefile head/games/hexalate/Makefile head/games/hoverboard-sdl/Makefile head/games/irrlamb/Makefile head/games/liblcf/Makefile head/games/libretro-cores/Makefile head/games/lordsawar/Makefile head/games/lugaru/Makefile head/games/megaglest/Makefile head/games/mirrormagic/Makefile head/games/naev/Makefile head/games/openclonk/Makefile head/games/openlierox/Makefile head/games/openmw/Makefile head/games/openomf/Makefile head/games/openspades/Makefile head/games/opensurge/Makefile head/games/openxcom/Makefile head/games/openyahtzee/Makefile head/games/peg-e/Makefile head/games/pingus/Makefile head/games/pioneer/Makefile head/games/py-mnemosyne/Makefile head/games/quackle/Makefile head/games/quakeforge/Makefile head/games/retroarch/Makefile head/games/rubix/Makefile head/games/sdl_scavenger/Makefile head/games/sdlroids/Makefile head/games/shaaft/Makefile head/games/simsu/Makefile head/games/slade/Makefile head/games/solarus/Makefile head/games/solarus-quest-editor/Makefile head/games/spring/Makefile head/games/springlobby/Makefile head/games/stonesoup/Makefile head/games/supertux2/Makefile head/games/supertuxkart/Makefile head/games/syobon/Makefile head/games/tanglet/Makefile head/games/tbe/Makefile head/games/teeworlds/Makefile head/games/tetzle/Makefile head/games/traingame/Makefile head/games/trenchbroom/Makefile head/games/ufoai/Makefile head/games/warsow/Makefile head/games/warzone2100/Makefile head/games/wesnoth/Makefile head/games/widelands/Makefile head/games/wxlauncher/Makefile head/games/wyrmgus/Makefile head/games/xbat/Makefile head/games/xonotic/Makefile head/graphics/GraphicsMagick/Makefile head/graphics/ImageMagick/Makefile head/graphics/ImageMagick7/Makefile head/graphics/OpenEXR/Makefile head/graphics/aaphoto/Makefile head/graphics/alembic/Makefile head/graphics/animorph/Makefile head/graphics/argyllcms/Makefile head/graphics/aseprite/Makefile head/graphics/blender/Makefile head/graphics/bugle/Makefile head/graphics/caffe/Makefile head/graphics/cegui/Makefile head/graphics/cimg/Makefile head/graphics/code-eli/Makefile head/graphics/colmap/Makefile head/graphics/converseen/Makefile head/graphics/copperspice/Makefile head/graphics/darktable/Makefile head/graphics/dataplot/Makefile head/graphics/dcp2icc/Makefile head/graphics/delaboratory/Makefile head/graphics/dilay/Makefile head/graphics/enblend/Makefile head/graphics/evince/Makefile head/graphics/freeimage/Makefile head/graphics/geomorph/Makefile head/graphics/gimp-beautify-plugin/Makefile head/graphics/gimp-gmic-plugin/Makefile head/graphics/gimp-refocus-plugin/Makefile head/graphics/gimp-resynthesizer/Makefile head/graphics/gle-graphics/Makefile head/graphics/gource/Makefile head/graphics/gthumb/Makefile head/graphics/gtimelapse/Makefile head/graphics/guetzli/Makefile head/graphics/hiptext/Makefile head/graphics/hugin/Makefile head/graphics/inkscape/Makefile head/graphics/ipe/Makefile head/graphics/jogamp-jogl/Makefile head/graphics/kf5-kimageformats/Makefile head/graphics/kf5-kplotting/Makefile head/graphics/kf5-prison/Makefile head/graphics/libbpg/Makefile head/graphics/libcdr01/Makefile head/graphics/libetonyek01/Makefile head/graphics/libfreehand/Makefile head/graphics/libgltf/Makefile head/graphics/libopenraw/Makefile head/graphics/libraw/Makefile head/graphics/lightzone/Makefile head/graphics/lximage-qt/Makefile head/graphics/mahotas/Makefile head/graphics/makehuman/Makefile head/graphics/mapnik/Makefile head/graphics/mhgui/Makefile head/graphics/mupdf/Makefile head/graphics/mypaint/Makefile head/graphics/nurbs++/Makefile head/graphics/ogre3d/Makefile head/graphics/openimageio/Makefile head/graphics/openshadinglanguage/Makefile head/graphics/oyranos/Makefile head/graphics/p5-PGPLOT/Makefile head/graphics/pfstmo/Makefile head/graphics/pgplot/Makefile head/graphics/photivo/Makefile head/graphics/piglit/Makefile head/graphics/pixie/Makefile head/graphics/py-gdal/Makefile head/graphics/qgis/Makefile head/graphics/raster3d/Makefile head/graphics/rawtherapee/Makefile head/graphics/rawtherapee-devel/Makefile head/graphics/seexpr/Makefile head/graphics/sekrit-twc-zimg/Makefile head/graphics/shotwell/Makefile head/graphics/simpleviewer/Makefile head/graphics/tesseract/Makefile head/graphics/tiled/Makefile head/graphics/tulip/Makefile head/graphics/vapoursynth-waifu2x-w2xc/Makefile head/graphics/vigra/Makefile head/graphics/waffle/Makefile head/graphics/waifu2x-converter-cpp/Makefile head/graphics/webp/Makefile head/graphics/wxsvg/Makefile head/graphics/xd3d/Makefile head/graphics/zathura/Makefile head/graphics/zathura-cb/Makefile head/graphics/zathura-djvu/Makefile head/graphics/zathura-pdf-mupdf/Makefile head/graphics/zathura-pdf-poppler/Makefile head/graphics/zathura-ps/Makefile head/irc/ezbounce/Makefile head/irc/ircd-ratbox/Makefile head/irc/ircservices/Makefile head/irc/quassel/Makefile head/irc/znc/Makefile head/japanese/fcitx-skk/Makefile head/japanese/mozc-server/Makefile head/japanese/skkinput3/Makefile head/japanese/xtr/Makefile head/java/classpath/Makefile head/java/intellij-fsnotifier/Makefile head/java/sigar/Makefile head/lang/afnix/Makefile head/lang/angelscript/Makefile head/lang/bigloo/Makefile head/lang/cilkplus/Makefile head/lang/cint/Makefile head/lang/cjs/Makefile head/lang/clang34/Makefile head/lang/clang35/Makefile head/lang/clang36/Makefile head/lang/cling/Makefile head/lang/erlang-runtime15/Makefile head/lang/erlang-runtime16/Makefile head/lang/erlang-runtime17/Makefile head/lang/erlang-runtime18/Makefile head/lang/gambit-c/Makefile head/lang/gcc6/Makefile head/lang/gcc6-devel/Makefile head/lang/gcc7-devel/Makefile head/lang/gforth/Makefile head/lang/ghc/Makefile head/lang/gjs/Makefile head/lang/gprolog/Makefile head/lang/hugs/Makefile head/lang/icon/Makefile head/lang/io/Makefile head/lang/julia/Makefile head/lang/kf5-kross/Makefile head/lang/mlton/Makefile head/lang/modula3/Makefile head/lang/mono/Makefile head/lang/oo2c/Makefile head/lang/opencoarrays/Makefile head/lang/p5-ExtUtils-F77/Makefile head/lang/phantomjs/Makefile head/lang/pure/Makefile head/lang/qscheme/Makefile head/lang/ratfor/Makefile head/lang/sagittarius-scheme/Makefile head/lang/scm/Makefile head/lang/spidermonkey170/Makefile head/lang/spidermonkey24/Makefile head/lang/v8/Makefile head/lang/v8-devel/Makefile head/lang/x10/Makefile head/lang/yap/Makefile head/lang/yap-devel/Makefile head/lang/ypsilon/Makefile head/mail/annoyance-filter/Makefile head/mail/dovecot2-pigeonhole/Makefile head/mail/libmapi/Makefile head/mail/libvmime/Makefile head/mail/milter-callback/Makefile head/mail/pop3vscan/Makefile head/mail/spamdyke/Makefile head/mail/spamprobe/Makefile head/mail/trojita/Makefile head/math/R/Makefile head/math/algae/Makefile head/math/armadillo/Makefile head/math/arpack/Makefile head/math/arpack-ng/Makefile head/math/aspcud/Makefile head/math/atlas/Makefile head/math/blacs/Makefile head/math/blocksolve95/Makefile head/math/cadabra2/Makefile head/math/cantor/Makefile head/math/carve/Makefile head/math/cblas/Makefile head/math/ceres-solver/Makefile head/math/clp/Makefile head/math/cmlib/Makefile head/math/cryptominisat/Makefile head/math/cvc3/Makefile head/math/drgeo/Makefile head/math/dynare/Makefile head/math/eispack/Makefile head/math/fflas-ffpack/Makefile head/math/fftw/Makefile head/math/fftw3/Makefile head/math/fityk/Makefile head/math/freemat/Makefile head/math/gambit/Makefile head/math/giacxcas/Makefile head/math/gotoblas/Makefile head/math/gracetmpl/Makefile head/math/gretl/Makefile head/math/gringo/Makefile head/math/hfst/Makefile head/math/ipopt/Makefile head/math/ised/Makefile head/math/jags/Makefile head/math/kig/Makefile head/math/kktdirect/Makefile head/math/labplot/Makefile head/math/lapack/Makefile head/math/lapack++/Makefile head/math/lapack95/Makefile head/math/levmar/Makefile head/math/libRmath/Makefile head/math/librsb/Makefile head/math/libtsnnls/Makefile head/math/linpack/Makefile head/math/math77/Makefile head/math/metis/Makefile head/math/miracl/Makefile head/math/mosesdecoder/Makefile head/math/mumps/Makefile head/math/octave/Makefile head/math/octave-forge-actuarial/Makefile head/math/octave-forge-audio/Makefile head/math/octave-forge-bim/Makefile head/math/octave-forge-bioinfo/Makefile head/math/octave-forge-cgi/Makefile head/math/octave-forge-civil-engineering/Makefile head/math/octave-forge-communications/Makefile head/math/octave-forge-control/Makefile head/math/octave-forge-data-smoothing/Makefile head/math/octave-forge-database/Makefile head/math/octave-forge-dataframe/Makefile head/math/octave-forge-divand/Makefile head/math/octave-forge-doctest/Makefile head/math/octave-forge-econometrics/Makefile head/math/octave-forge-engine/Makefile head/math/octave-forge-fenv/Makefile head/math/octave-forge-financial/Makefile head/math/octave-forge-fits/Makefile head/math/octave-forge-fl-core/Makefile head/math/octave-forge-fpl/Makefile head/math/octave-forge-fuzzy-logic-toolkit/Makefile head/math/octave-forge-ga/Makefile head/math/octave-forge-general/Makefile head/math/octave-forge-generate_html/Makefile head/math/octave-forge-geometry/Makefile head/math/octave-forge-gnuplot/Makefile head/math/octave-forge-gsl/Makefile head/math/octave-forge-ident/Makefile head/math/octave-forge-image/Makefile head/math/octave-forge-informationtheory/Makefile head/math/octave-forge-integration/Makefile head/math/octave-forge-interval/Makefile head/math/octave-forge-io/Makefile head/math/octave-forge-irsa/Makefile head/math/octave-forge-level-set/Makefile head/math/octave-forge-linear-algebra/Makefile head/math/octave-forge-lssa/Makefile head/math/octave-forge-ltfat/Makefile head/math/octave-forge-mapping/Makefile head/math/octave-forge-mechanics/Makefile head/math/octave-forge-miscellaneous/Makefile head/math/octave-forge-missing-functions/Makefile head/math/octave-forge-msh/Makefile head/math/octave-forge-multicore/Makefile head/math/octave-forge-mvn/Makefile head/math/octave-forge-nan/Makefile head/math/octave-forge-ncarray/Makefile head/math/octave-forge-netcdf/Makefile head/math/octave-forge-nlwing2/Makefile head/math/octave-forge-nnet/Makefile head/math/octave-forge-nurbs/Makefile head/math/octave-forge-ocs/Makefile head/math/octave-forge-oct2mat/Makefile head/math/octave-forge-octcdf/Makefile head/math/octave-forge-octclip/Makefile head/math/octave-forge-octproj/Makefile head/math/octave-forge-odebvp/Makefile head/math/octave-forge-odepkg/Makefile head/math/octave-forge-optics/Makefile head/math/octave-forge-optim/Makefile head/math/octave-forge-optiminterp/Makefile head/math/octave-forge-outliers/Makefile head/math/octave-forge-parallel/Makefile head/math/octave-forge-pdb/Makefile head/math/octave-forge-plot/Makefile head/math/octave-forge-pt_br/Makefile head/math/octave-forge-quaternion/Makefile head/math/octave-forge-queueing/Makefile head/math/octave-forge-secs1d/Makefile head/math/octave-forge-secs2d/Makefile head/math/octave-forge-secs3d/Makefile head/math/octave-forge-signal/Makefile head/math/octave-forge-simp/Makefile head/math/octave-forge-sockets/Makefile head/math/octave-forge-sparsersb/Makefile head/math/octave-forge-specfun/Makefile head/math/octave-forge-special-matrix/Makefile head/math/octave-forge-splines/Makefile head/math/octave-forge-statistics/Makefile head/math/octave-forge-stk/Makefile head/math/octave-forge-strings/Makefile head/math/octave-forge-struct/Makefile head/math/octave-forge-symband/Makefile head/math/octave-forge-symbolic/Makefile head/math/octave-forge-tcl-octave/Makefile head/math/octave-forge-tisean/Makefile head/math/octave-forge-tsa/Makefile head/math/octave-forge-video/Makefile head/math/octave-forge-zenity/Makefile head/math/octave-forge-zeromq/Makefile head/math/openblas/Makefile head/math/openfst/Makefile head/math/opensolaris-libm/Makefile head/math/p5-Math-Int128/Makefile head/math/pdal/Makefile head/math/plplot/Makefile head/math/py-cryptominisat/Makefile head/math/py-matplotlib/Makefile head/math/py-numpy/Makefile head/math/py-pysparse/Makefile head/math/py-symeig/Makefile head/math/py-theano/Makefile head/math/qalculate/Makefile head/math/qd/Makefile head/math/qrupdate/Makefile head/math/rkward-kde4/Makefile head/math/rpy2/Makefile head/math/saga/Makefile head/math/scalapack/Makefile head/math/scilab/Makefile head/math/sdpa/Makefile head/math/sdpara/Makefile head/math/sfft/Makefile head/math/slatec/Makefile head/math/spblas/Makefile head/math/suitesparse/Makefile head/math/superlu/Makefile head/math/superlu_mt/Makefile head/math/taucs/Makefile head/math/tomsfastmath/Makefile head/math/trlan/Makefile head/math/vowpal_wabbit/Makefile head/math/wfmath/Makefile head/math/x12arima/Makefile head/math/yacas/Makefile head/misc/estic/Makefile head/misc/rump/Makefile head/misc/seabios/Makefile head/misc/terraform/Makefile head/multimedia/aegisub/Makefile head/multimedia/assimp/Makefile head/multimedia/audacious/Makefile head/multimedia/audacious-gtk3/Makefile head/multimedia/audacious-plugins/Makefile head/multimedia/audacious-plugins-gtk3/Makefile head/multimedia/baka-mplayer/Makefile head/multimedia/bombono/Makefile head/multimedia/dvdstyler/Makefile head/multimedia/ffmpeg/Makefile head/multimedia/ffmpegthumbnailer/Makefile head/multimedia/ffms2/Makefile head/multimedia/gstreamer1-vaapi/Makefile head/multimedia/kf5-kmediaplayer/Makefile head/multimedia/kissdx/Makefile head/multimedia/kodi/Makefile head/multimedia/kvazaar/Makefile head/multimedia/libcec/Makefile head/multimedia/libde265/Makefile head/multimedia/libva-intel-driver/Makefile head/multimedia/libvpx/Makefile head/multimedia/lives/Makefile head/multimedia/mjpegtools/Makefile head/multimedia/mkvtoolnix/Makefile head/multimedia/mpc-qt/Makefile head/multimedia/mpv/Makefile head/multimedia/obs-studio/Makefile head/multimedia/oggvideotools/Makefile head/multimedia/pHash/Makefile head/multimedia/rage/Makefile head/multimedia/vapoursynth/Makefile head/multimedia/vdr/Makefile head/multimedia/vdr-plugin-softhddevice/Makefile head/multimedia/vlc/Makefile head/multimedia/x264/Makefile head/multimedia/xanim/Makefile head/net/belle-sip/Makefile head/net/corosync/Makefile head/net/freerdp/Makefile head/net/freerdp1/Makefile head/net/glusterfs/Makefile head/net/gnome-online-accounts/Makefile head/net/gupnp/Makefile head/net/iaxmodem/Makefile head/net/ipxe/Makefile head/net/kea/Makefile head/net/kf5-kxmlrpcclient/Makefile head/net/l2tpd/Makefile head/net/libtnl/Makefile head/net/mediatomb/Makefile head/net/mpich/Makefile head/net/mpich2/Makefile head/net/ndisc6/Makefile head/net/ndpi/Makefile head/net/nepenthes/Makefile head/net/ohphone/Makefile head/net/openbsc/Makefile head/net/openh323/Makefile head/net/openmpi/Makefile head/net/openmpi2/Makefile head/net/opensips/Makefile head/net/pacemaker/Makefile head/net/quagga/Makefile head/net/skstream/Makefile head/net/spoofer/Makefile head/net/uget/Makefile head/net/xpvm/Makefile head/net/yami4/Makefile head/net/zerotier/Makefile head/net-im/diligent/Makefile head/net-im/jabberd/Makefile head/net-im/ktp-common-internals/Makefile head/net-im/ktp-text-ui/Makefile head/net-im/libaccounts-qt5/Makefile head/net-im/qTox/Makefile head/net-im/ricochet/Makefile head/net-im/ring-daemon/Makefile head/net-im/ring-gnome/Makefile head/net-im/ring-libclient/Makefile head/net-im/teamwords/Makefile head/net-im/telegram-purple/Makefile head/net-im/tox/Makefile head/net-im/uTox/Makefile head/net-mgmt/chillispot/Makefile head/net-mgmt/mk-livestatus/Makefile head/net-mgmt/resource-agents/Makefile head/net-mgmt/seafile-gui/Makefile head/net-p2p/bitcoin/Makefile head/net-p2p/cpuminer/Makefile head/net-p2p/dogecoin/Makefile head/net-p2p/eiskaltdcpp-daemon/Makefile head/net-p2p/eiskaltdcpp-gtk/Makefile head/net-p2p/eiskaltdcpp-lib/Makefile head/net-p2p/eiskaltdcpp-qt/Makefile head/net-p2p/go-ethereum/Makefile head/net-p2p/libtorrent/Makefile head/net-p2p/libtorrent-rasterbar/Makefile head/net-p2p/namecoin/Makefile head/net-p2p/qbittorrent/Makefile head/net-p2p/rtorrent/Makefile head/net-p2p/transmission-qt4/Makefile head/net-p2p/zetacoin/Makefile head/news/nzbget/Makefile head/palm/jpilot/Makefile head/polish/kadu/Makefile head/polish/qnapi/Makefile head/ports-mgmt/octopkg/Makefile head/ports-mgmt/portal/Makefile head/ports-mgmt/portrac/Makefile head/print/cups-filters/Makefile head/print/gribouy/Makefile head/print/harfbuzz/Makefile head/print/libmspub01/Makefile head/print/pdftk/Makefile head/science/cdf/Makefile head/science/cgnslib/Makefile head/science/clhep/Makefile head/science/dcl/Makefile head/science/dlpoly-classic/Makefile head/science/fvcom/Makefile head/science/fvm/Makefile head/science/getdp/Makefile head/science/ghemical/Makefile head/science/gnudatalanguage/Makefile head/science/gromacs/Makefile head/science/harminv/Makefile head/science/hdf/Makefile head/science/hdf5/Makefile head/science/hdf5-18/Makefile head/science/isaac-cfd/Makefile head/science/libctl/Makefile head/science/libgeodecomp/Makefile head/science/libghemical/Makefile head/science/libint/Makefile head/science/libxc/Makefile head/science/massxpert/Makefile head/science/mbdyn/Makefile head/science/meep/Makefile head/science/mpb/Makefile head/science/mpqc/Makefile head/science/ncs/Makefile head/science/netcdf-fortran/Makefile head/science/openkim/Makefile head/science/pnetcdf/Makefile head/science/psychopy/Makefile head/science/py-obspy/Makefile head/science/py-scikit-learn/Makefile head/science/py-scikit-sparse/Makefile head/science/py-scipy/Makefile head/science/silo/Makefile head/science/v_sim/Makefile head/security/arpCounterattack/Makefile head/security/bearssl/Makefile head/security/bro/Makefile head/security/certificate-transparency/Makefile head/security/clamav/Makefile head/security/clambc/Makefile head/security/cryptopp/Makefile head/security/gnome-keyring/Makefile head/security/gnupg/Makefile head/security/gpgme/Makefile head/security/hashcat-legacy/Makefile head/security/hpenc/Makefile head/security/i2pd/Makefile head/security/john/Makefile head/security/keepassx-devel/Makefile head/security/keepassxc/Makefile head/security/kf5-kdesu/Makefile head/security/libzrtpcppcore/Makefile head/security/obfsclient/Makefile head/security/pinentry/Makefile head/security/pks/Makefile head/security/quantis/Makefile head/security/seccure/Makefile head/security/titus/Makefile head/sysutils/android-file-transfer/Makefile head/sysutils/b2sum/Makefile head/sysutils/bsdisks/Makefile head/sysutils/clone/Makefile head/sysutils/cloudabi-utils/Makefile head/sysutils/conky/Makefile head/sysutils/dar/Makefile head/sysutils/facter/Makefile head/sysutils/freefilesync/Makefile head/sysutils/fusefs-encfs/Makefile head/sysutils/fusefs-lkl/Makefile head/sysutils/fusefs-simple-mtpfs/Makefile head/sysutils/gnome-control-center/Makefile head/sysutils/grub2/Makefile head/sysutils/grub2-bhyve/Makefile head/sysutils/grub2-efi/Makefile head/sysutils/grub2-pcbsd/Makefile head/sysutils/hfm/Makefile head/sysutils/i7z/Makefile head/sysutils/ipdbtools/Makefile head/sysutils/kf5-baloo/Makefile head/sysutils/kf5-kwallet/Makefile head/sysutils/kshutdown-kde4/Makefile head/sysutils/libretto-config/Makefile head/sysutils/logstalgia/Makefile head/sysutils/mate-system-monitor/Makefile head/sysutils/osquery/Makefile head/sysutils/parafly/Makefile head/sysutils/pesign/Makefile head/sysutils/polkit/Makefile head/sysutils/powerdxx/Makefile head/sysutils/shim/Makefile head/sysutils/spiped/Makefile head/sysutils/tarsnap-gui/Makefile head/sysutils/wiimms/Makefile head/textproc/ctpp2/Makefile head/textproc/fcitx-qt5/Makefile head/textproc/gutenmark/Makefile head/textproc/highlight/Makefile head/textproc/ibus/Makefile head/textproc/kenlm/Makefile head/textproc/kf5-kcodecs/Makefile head/textproc/kf5-sonnet/Makefile head/textproc/kf5-syntax-highlighting/Makefile head/textproc/libe-book/Makefile head/textproc/libsass/Makefile head/textproc/libvisio01/Makefile head/textproc/opengrm-ngram/Makefile head/textproc/pdfgrep/Makefile head/textproc/pugixml/Makefile head/textproc/randlm/Makefile head/textproc/sassc/Makefile head/textproc/senna/Makefile head/textproc/sigil/Makefile head/textproc/uim-kde4/Makefile head/textproc/wiggle/Makefile head/textproc/yodl/Makefile head/textproc/zorba/Makefile head/www/anyterm/Makefile head/www/aria2/Makefile head/www/edbrowse/Makefile head/www/epiphany/Makefile head/www/gecko-mediaplayer/Makefile head/www/h2o/Makefile head/www/hiawatha/Makefile head/www/kannel/Makefile head/www/kannel-sqlbox/Makefile head/www/kf5-kdewebkit/Makefile head/www/kf5-khtml/Makefile head/www/kf5-kjs/Makefile head/www/kf5-kjsembed/Makefile head/www/mod_authnz_crowd/Makefile head/www/mod_spdy/Makefile head/www/newsbeuter/Makefile head/www/nghttp2/Makefile head/www/node/Makefile head/www/node4/Makefile head/www/node6/Makefile head/www/otter-browser/Makefile head/www/p5-Gtk2-WebKit/Makefile head/www/rejik/Makefile head/www/spdylay/Makefile head/www/squid-devel/Makefile head/www/webkit-gtk2/Makefile head/www/webkit-gtk3/Makefile head/www/webkit2-gtk3/Makefile head/www/wt/Makefile head/x11/cinnamon/Makefile head/x11/cool-retro-term/Makefile head/x11/eaglemode/Makefile head/x11/gnome-shell/Makefile head/x11/kactivities/Makefile head/x11/kactivitymanagerd/Makefile head/x11/kde4-workspace/Makefile head/x11/kf5-frameworkintegration/Makefile head/x11/kf5-kactivities/Makefile head/x11/kf5-kded/Makefile head/x11/kf5-kdelibs4support/Makefile head/x11/kf5-kglobalaccel/Makefile head/x11/kf5-kinit/Makefile head/x11/kf5-krunner/Makefile head/x11/kf5-kwayland/Makefile head/x11/kf5-kwindowsystem/Makefile head/x11/kf5-plasma-framework/Makefile head/x11/lemonbar/Makefile head/x11/libfm-qt/Makefile head/x11/qterminal/Makefile head/x11/terminology/Makefile head/x11/thingylaunch/Makefile head/x11/virtualgl/Makefile head/x11/xpra/Makefile head/x11-fm/gnome-commander2/Makefile head/x11-fm/pcmanfm-qt/Makefile head/x11-fm/wcmcommander/Makefile head/x11-fm/worker/Makefile head/x11-themes/adwaita-qt4/Makefile head/x11-themes/adwaita-qt5/Makefile head/x11-themes/kf5-kemoticons/Makefile head/x11-themes/kf5-kiconthemes/Makefile head/x11-themes/qt4-style-Kvantum/Makefile head/x11-themes/qt5-style-Kvantum/Makefile head/x11-themes/qtcurve/Makefile head/x11-toolkits/c++-gtk-utils/Makefile head/x11-toolkits/fox17/Makefile head/x11-toolkits/kf5-attica/Makefile head/x11-toolkits/kf5-kcompletion/Makefile head/x11-toolkits/kf5-kconfigwidgets/Makefile head/x11-toolkits/kf5-kdesignerplugin/Makefile head/x11-toolkits/kf5-kguiaddons/Makefile head/x11-toolkits/kf5-kitemviews/Makefile head/x11-toolkits/kf5-kjobwidgets/Makefile head/x11-toolkits/kf5-ktextwidgets/Makefile head/x11-toolkits/kf5-kwidgetsaddons/Makefile head/x11-toolkits/kf5-kxmlgui/Makefile head/x11-toolkits/kirigami/Makefile head/x11-toolkits/kirigami2/Makefile head/x11-toolkits/mygui/Makefile head/x11-toolkits/p5-Wx/Makefile head/x11-toolkits/py-wxPython30/Makefile head/x11-toolkits/qtermwidget/Makefile head/x11-toolkits/scintilla/Makefile head/x11-toolkits/vte3/Makefile head/x11-toolkits/wxgtk30/Makefile head/x11-wm/herbstluftwm/Makefile head/x11-wm/metacity/Makefile head/x11-wm/mutter/Makefile --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Apr 1 15:27:59 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 3A4C4D296F7 for ; Sat, 1 Apr 2017 15:27:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EDCF1E5 for ; Sat, 1 Apr 2017 15:27:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v31FRwIi069582 for ; Sat, 1 Apr 2017 15:27:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216707] exp-run: Update lang/gcc from GCC 4.9 to GCC 5 Date: Sat, 01 Apr 2017 15:27:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Ports Framework X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: gerald@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: portmgr@FreeBSD.org X-Bugzilla-Flags: merge-quarterly+ X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sat, 01 Apr 2017 15:27:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216707 Gerald Pfeifer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED --=20 You are receiving this mail because: You are on the CC list for the bug.=