From owner-freebsd-ppc@freebsd.org Mon Apr 3 18:38:54 2017 Return-Path: Delivered-To: freebsd-ppc@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 73AD9D2CAE2 for ; Mon, 3 Apr 2017 18:38:54 +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 329686DC for ; Mon, 3 Apr 2017 18:38:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 801 invoked from network); 3 Apr 2017 18:38:52 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 3 Apr 2017 18:38:52 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 03 Apr 2017 14:38:52 -0400 (EDT) Received: (qmail 22382 invoked from network); 3 Apr 2017 18:38:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Apr 2017 18:38:52 -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 85632EC91EB; Mon, 3 Apr 2017 11:38:51 -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: Mon, 3 Apr 2017 11:38:50 -0700 Cc: FreeBSD Toolchain , FreeBSD Current , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <543D47AE-7C0D-4F0E-83B4-BFEE5B802346@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> <20170329155316.GK59667@spindle.one-eyed-alien.net> To: Brooks Davis , Dimitry Andric , FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 18:38:54 -0000 On 2017-Apr-1, at 3:51 AM, Mark Millard wrote: > On 2017-Mar-31, at 4:51 PM, Mark Millard = wrote: >=20 >> 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: >=20 > 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. >=20 > For now I presume that what I reported was okay and so > I continue to refer to these figures later below. The retry got the same 42 GiByte and 102 GiByte sizes. (And again I was not monitoring the swap space usage.) So functionality like ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG (keeping optimization flags in CFLAGS) does not contribute to devel/llvm40's handling. Apparently the CMAKE_BUILD_TYPE has full control over such and RelWithDebInfo still makes for a massive build, though not as big as for DEBUG. For my context I've chosen to go with: # # =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 (where ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG is from a local change to /usr/ports/Mk/bsd.port.mk but is not justified via devel/llvm* ports but via behavior for most other ports.) >> # 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.] >=20 > I've also tried without WITH_DEBUG=3D and now. . . >=20 >=20 > # pkg delete llvm40 > Checking integrity... done (0 conflicting) > Deinstallation has been requested for the following 1 packages (of 0 = packages in the universe): >=20 > Installed packages to be REMOVED: > llvm40-4.0.0 >=20 > Number of packages to be removed: 1 >=20 > The operation will free 1 GiB. >=20 > Proceed with deinstalling packages? [y/N]: n >=20 >=20 > # du -sg /usr/obj/portswork/usr/ports/devel/llvm40/ > 5 /usr/obj/portswork/usr/ports/devel/llvm40/ >=20 >=20 > So the alternatives (with everything built each time): >=20 > (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) >=20 >=20 > I'll likely end up having /etc/make.conf contain > something like the following for most or all of > my FreeBSD environments: >=20 > # > # =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 >=20 >=20 > Along with using: >=20 > # 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 >=20 >=20 > [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-ppc@freebsd.org Mon Apr 3 18:44:00 2017 Return-Path: Delivered-To: freebsd-ppc@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 71DC2D2CE2C for ; Mon, 3 Apr 2017 18:44:00 +0000 (UTC) (envelope-from andy.silva@snsresearchreports.com) Received: from mailer238.gate85.rs.smtp.com (mailer238.gate85.rs.smtp.com [74.91.85.238]) (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 3179ECD2 for ; Mon, 3 Apr 2017 18:43:59 +0000 (UTC) (envelope-from andy.silva@snsresearchreports.com) X-MSFBL: zcVdynPD6eflAD+hA/ajBPvoJuP4nVGUsXMxgo2G6Nc=|eyJiIjoiNzRfOTFfODV fMjM4IiwiZyI6IlNuc3RlbGVjb21fZGVkaWNhdGVkX3Bvb2wiLCJyIjoiZnJlZWJ zZC1wcGNAZnJlZWJzZC5vcmcifQ== Received: from [192.168.80.21] ([192.168.80.21:38846] helo=rs-ord-mta02-in1.smtp.com) by rs-ord-mta01-out2.smtp.com (envelope-from ) (ecelerity 4.2.1.55028 r(Core:4.2.1.12)) with ESMTP id 47/12-12339-A2392E85; Mon, 03 Apr 2017 18:23:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=snsresearchreports.com; s=snskey; c=relaxed/simple; q=dns/txt; i=@snsresearchreports.com; t=1491243818; h=From:Subject:To:Date:MIME-Version:Content-Type; bh=nfXjIywWC53ZmFbC5kRbaOSjweeZuKoL8Pislz0HFyQ=; b=M7+IV5CBzltJnMKPXiNJEmnbSZTHOmGCw2GqW+cZXkjl9+R7rx75iiRzbOYNT7GI Jim8P3kq4H5YhwZf9ltVnmVg1+Eztr1o9Ripi0PH6EvOWUMSZCKrFOPF5OHAB0aX NAjmMy8ihwG/bXlh7s71lwjI/Jg55R/JDpfSkgAOlk0tW1u5bjXGJ3nNWBInav/E 8aakCtw3tAGJqfuRZogSQL6n3BsYBZ5s0bks/N1N0LrYjQoYVnAI2QUiKQmqLK6E Ay7wtFrVjmASL/yVqwxtYgubl0HDeW1FguZLQ18BOuSNArdALBVdbtRtMBUcYOKw vUkXsAyyOypayCSFi47qpg==; Received: from [70.79.69.78] ([70.79.69.78:37400] helo=S01061c1b689e28c7.vc.shawcable.net) by rs-ord-mta02-in1.smtp.com (envelope-from ) (ecelerity 4.1.0.46749 r(Core:4.1.0.4)) with ESMTPA id 87/27-17964-92392E85; Mon, 03 Apr 2017 18:23:38 +0000 MIME-Version: 1.0 From: "Andy Silva" Reply-To: andy.silva@snsresearchreports.com To: freebsd-ppc@freebsd.org Subject: 5G Wireless Ecosystem: 2017 - 2030 - Technologies, Applications, Verticals, Strategies & Forecasts (Report) X-Mailer: Smart_Send_2_0_138 Date: Mon, 3 Apr 2017 11:23:28 -0700 Message-ID: <32404347506481892412727@Ankur> X-Report-Abuse: SMTP.com is an email service provider. Our abuse team cares about your feedback. Please contact abuse@smtp.com for further investigation. X-SMTPCOM-Tracking-Number: ea1d6085-94b8-477f-9f20-02be152707cd X-SMTPCOM-Sender-ID: 6008902 Feedback-ID: 6008902:SMTPCOM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 18:44:00 -0000 5G Wireless Ecosystem: 2017 =96 2030 =96 Technologies, Applications, Vertic= als, Strategies & Forecasts (Report) Hello Let me offer you the latest SNS Research report to you and your team, "5G W= ireless Ecosystem: 2017 =96 2030 =96 Technologies, Applications, Verticals,= Strategies & Forecasts" Below is the report highlight and if you like I ca= n send you sample pages for your details inside. Despite the lack of sufficient LTE coverage in parts of the world, mobile o= perators and vendors have already embarked on R&D initiatives to develop 5G= , the next evolution in mobile networks. 5G is expected to provide a single= network environment to deliver not only existing mobile broadband and IoT = services, but also new innovations such as self-driving cars, cloud robotic= s, 3D holographic telepresence and remote surgery with haptic feedback. Although 2020 has conventionally been regarded as the headline date for 5G = commercialization, the very first standardized deployments of the technolog= y are expected to be commercialized as early as 2019 with the 3GPP's initia= l 5G specifications set to be implementation-ready by March 2018. Between 2= 019 and 2025, we expect the 5G network infrastructure market to aggressivel= y grow a CAGR of nearly 70%, eventually accounting for $28 Billion in annua= l spending by the end of 2025. These infrastructure investments will be com= plemented by annual shipments of up to 520 Million 5G-capable devices. The report comes with an associated Excel datasheet suite covering quantita= tive data from all numeric forecasts presented in the report, as well as a = 5G deployment tracking database covering over 60 global 5G trials, demos an= d commercial deployment commitments (as of Q1=922017). Report Information: Release Date: March 2017 Number of Pages: 363 Number of Tables and Figures: 117 Key Questions Answered: How big is the opportunity for 5G network infrastructure, user equipment an= d operator services=3F What trends, challenges and barriers will influence the development and ado= ption of 5G=3F How will 5G drive the adoption of AR (Augmented Reality)/VR (Virtual Realit= y) applications such as 3D holographic telepresence and 360 degree streamin= g of live events=3F How have advanced antenna and chip technologies made it possible to utilize= millimeter wave spectrum for mobile communications in 5G networks=3F How can non-orthogonal multiple access schemes such as RSMA (Resource Sprea= d Multiple Access) enable 5G networks to support higher connection densitie= s for Millions of IoT devices=3F What will be the number of 5G subscriptions in 2019 and at what rate will i= t grow=3F Which regions and countries will be the first to adopt 5G=3F Which frequency bands are most likely to be utilized by 5G networks=3F Who are the key 5G vendors and what are their strategies=3F Will 5G networks rely on a disaggregated RAN architecture=3F How will 5G impact the fiber industry=3F Will satellite communications and aerial networking platforms play a wider = role in 5G networks=3F Key Findings: The report has the following key findings: The Unites States and South Korea are spearheading early investments in pre= -standards 5G trial networks, as mobile operators rush to be the first to o= ffer 5G services. SNS Research estimates that by the end of 2017, pre-stand= ards 5G network investments are expected to account for over $250 Million. Following completion of the 3GPP's first phase of 5G specifications in Marc= h 2018, SNS Research expects that early adopters across the globe will simu= ltaneously begin commercializing 5G services in 2019. Between 2019 and 2025, we expect the 5G network infrastructure market to ag= gressively grow a CAGR of nearly 70%, eventually accounting for $28 Billion= in annual spending by the end of 2025. Although early 5G R&D investments have primarily targeted the radio access = segment, network-slicing has recently emerged as necessary "end-to-end" cap= ability to guarantee performance for different 5G applications which may ha= ve contrasting requirements. In order to support diverse usage scenarios, 5G networks are expected to ut= ilize a variety of frequency bands ranging from established sub-6 GHz cellu= lar bands to millimeter wave spectrum. The report covers the following topics: 5G NR (New Radio) and NextGen (Next Generation) system architecture Market drivers and barriers to the adoption of 5G networks 5G requirements, usage scenarios, vertical markets and applications Key enabling technologies including air interface design, higher frequency = radio access, advanced antenna systems, flexible duplex schemes, D2D (Devic= e-to-Device) connectivity, dynamic spectrum access, self-backhauling and network slicing Complementary concepts including NFV, SDN, hyperscale data centers, Cloud R= AN, satellite communications and aerial networking platforms Case studies and review of mobile operator 5G commitments 5G standardization, development and research initiatives Analysis of spectrum availability and allocation strategies for 5G networks Competitive assessment of vendor strategies Review of investments on R&D and pre-standards 5G networks Standardized 5G infrastructure, user equipment and operator service forecas= ts till 2030 Forecast Segmentation: Market forecasts are provided for each of the following submarkets and thei= r subcategories: 5G R&D Investments New Air Interface & Millimeter Wave Radio Access MIMO, Beamforming & Advanced Antenna Technologies Spectrum Sharing, Aggregation & Interference Management Virtualization & Cloud RAN Network Slicing & Other Technologies Pre-Standards 5G Network Investments Pre-Standards Base Stations Pre-Standards User Equipment Transport Networking & Other Investments Standardized 5G Infrastructure Investments 5G NR (New Radio) Distributed Macrocell Base Stations Small Cells RRHs (Remote Radio Heads) C-RAN BBUs (Baseband Units) NextGen (Next Generation) Core Network Fronthaul & Backhaul Networking Standardized 5G User Equipment Investments Handsets Tablets Embedded IoT Modules USB Dongles Routers 5G Operator Services Subscriptions Service Revenue Regional Segmentation Asia Pacific Eastern Europe Latin & Central America Middle East & Africa North America Western Europe Report Pricing: =20 Single User License: USD 2,500 Company Wide License: USD 3,500 =20 Ordering Process: =20 Please provide the following information: Report Title - Report License - (Single User/Company Wide) Name - Email - Job Title - Company - Invoice Address - Please contact me if you have any questions, like to see table of contents,= sample pages or wish to purchase a copy. I look forward to hearing from you. =20 Kind Regards =20 Andy Silva Marketing Executive Signals and Systems Telecom andy.silva@snsresearchreports.com =20 =20 =20 To unsubscribe send an email with unsubscribe in the subject line to: remov= e@snsreports.com =20 From owner-freebsd-ppc@freebsd.org Wed Apr 5 16:15:42 2017 Return-Path: Delivered-To: freebsd-ppc@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 24483D30339; Wed, 5 Apr 2017 16:15:42 +0000 (UTC) (envelope-from danfe@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 038BA7A6; Wed, 5 Apr 2017 16:15:42 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 2DFA33568; Wed, 5 Apr 2017 16:15:41 +0000 (UTC) Date: Wed, 5 Apr 2017 16:15:41 +0000 From: Alexey Dokuchaev To: Matthew Rezny 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) Message-ID: <20170405161541.GA32323@FreeBSD.org> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> <2502554.oHoOYGyFJH@workstation.reztek> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2502554.oHoOYGyFJH@workstation.reztek> User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 16:15:42 -0000 On Thu, Mar 30, 2017 at 07:26:43PM +0200, Matthew Rezny wrote: > LLVM 3.8 introduced the option to build a shared LLVM library, which is > what Mesa needs for use at runtime (for e.g. compiling shaders), separate > from linking to it. Previous versions only had one option, if the library > was built then all the LLVM binaries were staticly linked to it. [...] > > llvm{35,36,37} are statically linked and thus smaller than normal. llvm38 > switched to dynamic linking, the default, thus the size grew. Hmm, I don't quite get it: shouldn't static linking actually increase the binaries (and thus the package) size? > I assume llvm40 will be a bit bigger, but do not expect to see another > jump as you've observed. As Mark Millard reports: > I've also tried without WITH_DEBUG= and now. . . > > # pkg delete llvm40 > Checking integrity... done (0 conflicting) > Deinstallation has been requested for the following 1 packages (of 0 > packages in the universe): > > Installed packages to be REMOVED: > llvm40-4.0.0 > > Number of packages to be removed: 1 > > The operation will free 1 GiB. That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. I'm surely looking forward modularization of LLVM port; rebuilding it every time becomes a real PITA given that X11 stack requires it. :-( ./danfe From owner-freebsd-ppc@freebsd.org Wed Apr 5 16:44:56 2017 Return-Path: Delivered-To: freebsd-ppc@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 71E0AD30F3B; Wed, 5 Apr 2017 16:44:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 2D5D4E08; Wed, 5 Apr 2017 16:44:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cvo39-000Fqa-7F; Wed, 05 Apr 2017 19:44:51 +0300 Date: Wed, 5 Apr 2017 19:44:51 +0300 From: Slawa Olhovchenkov To: Alexey Dokuchaev Cc: Matthew Rezny , 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) Message-ID: <20170405164451.GD20974@zxy.spb.ru> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> <2502554.oHoOYGyFJH@workstation.reztek> <20170405161541.GA32323@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170405161541.GA32323@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 16:44:56 -0000 On Wed, Apr 05, 2017 at 04:15:41PM +0000, Alexey Dokuchaev wrote: > > I've also tried without WITH_DEBUG= and now. . . > > > > # pkg delete llvm40 > > Checking integrity... done (0 conflicting) > > Deinstallation has been requested for the following 1 packages (of 0 > > packages in the universe): > > > > Installed packages to be REMOVED: > > llvm40-4.0.0 > > > > Number of packages to be removed: 1 > > > > The operation will free 1 GiB. > > That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. > I'm surely looking forward modularization of LLVM port; rebuilding it > every time becomes a real PITA given that X11 stack requires it. :-( What real reason of requiring llvm for X11? I am about run time depends: # pkg info -r llvm39 llvm39-3.9.1_4: libEGL-13.0.6 dri-13.0.6,2 # ldd /usr/local/lib/libXvMCr600.so /usr/local/lib/libXvMCr600.so: [...] libLLVM-3.9.so => /usr/local/llvm39/lib/libLLVM-3.9.so (0x803e00000) libLTO.so => /usr/local/llvm39/lib/../lib/libLTO.so (0x808200000) [...] # ls -lh /usr/local/llvm39/lib/libLLVM-3.9.so /usr/local/llvm39/lib/../lib/libLTO.so -rwxr-xr-x 1 root wheel 38M Apr 2 18:18 /usr/local/llvm39/lib/../lib/libLTO.so -rwxr-xr-x 1 root wheel 47M Apr 2 18:18 /usr/local/llvm39/lib/libLLVM-3.9.so libXvMCr600 realy do run-time llvm interpetation and linker-time optimisation?! Also, I am don't see any realy dependence libEGL-13.0.6 from llvm. From owner-freebsd-ppc@freebsd.org Wed Apr 5 17:02:13 2017 Return-Path: Delivered-To: freebsd-ppc@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 9B4EDD30826; Wed, 5 Apr 2017 17:02:13 +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 5C8E0661; Wed, 5 Apr 2017 17:02:13 +0000 (UTC) (envelope-from rezny@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1406) id 79DB8469C; Wed, 5 Apr 2017 17:02:12 +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: Wed, 05 Apr 2017 19:01:35 +0200 Message-ID: <2629274.jcOtFEnjsX@workstation.reztek> Organization: FreeBSD User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20170405161541.GA32323@FreeBSD.org> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <2502554.oHoOYGyFJH@workstation.reztek> <20170405161541.GA32323@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 17:02:13 -0000 On Wednesday 05 April 2017 16:15:41 Alexey Dokuchaev wrote: > On Thu, Mar 30, 2017 at 07:26:43PM +0200, Matthew Rezny wrote: > > LLVM 3.8 introduced the option to build a shared LLVM library, which is > > what Mesa needs for use at runtime (for e.g. compiling shaders), separate > > from linking to it. Previous versions only had one option, if the library > > was built then all the LLVM binaries were staticly linked to it. [...] > > > > llvm{35,36,37} are statically linked and thus smaller than normal. llvm38 > > switched to dynamic linking, the default, thus the size grew. > > Hmm, I don't quite get it: shouldn't static linking actually increase the > binaries (and thus the package) size? > I might have reversed static and shared somewhere in the linking explanation, or not properly described the situation. Versions prior to 3.8 could either build libLLVM as a static library and link all the LLVM binaries to that (recommended), or build it as a shared library and link the LLVM binaries to that (recommended for development only, but Mesa needs libLLVM.so). LLVM 3.8 introduced the 3rd option, build the shared library for external use, i.e. Mesa, but link the LLVM binaries to the libLLVM*.a bits that were used to build the shared library. llvm37 was built the non-recommended way for the benefit of Mesa, the LLVM binaries were linked to the shared library that Mesa used. llvm38 turned building/linking of the shared library, so there would be some increase since each LLVM binary now had that portion static linked. llvm39 turned on building of the shared library but did not enable linking with it so the LLVM binaries remain linking that part static, meaning the package grows by the size the shared library that is installed but not used by LLVM itself. Those were changes to a portion, not a complete change between static and shared linking for the whole package, so I was somewhat surprised by the size difference you noted, but of course I had forgotten that all the parts were collapsed into the llvm port. There was a brief period in which llvm39 was fully switched to dynamic linking, which made it considerably smaller but caused runtime problems (and was also likely to be slower). > > I assume llvm40 will be a bit bigger, but do not expect to see another > > jump as you've observed. > > As Mark Millard reports: > > I've also tried without WITH_DEBUG= and now. . . > > > > # pkg delete llvm40 > > Checking integrity... done (0 conflicting) > > Deinstallation has been requested for the following 1 packages (of 0 > > packages in the universe): > > > > Installed packages to be REMOVED: > > llvm40-4.0.0 > > > > Number of packages to be removed: 1 > > > > The operation will free 1 GiB. > > That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. > I'm surely looking forward modularization of LLVM port; rebuilding it > every time becomes a real PITA given that X11 stack requires it. :-( > > ./danfe I have both llvm39 and llvm40 installed here (amd64) with all options enabled and without any WITH_DEBUG. According to pkg, the flat (installed) size of llvm39 is 1.10GB and llvm40 is 1.31GB, so not a huge difference (<20%) but still steady growth. The best solution to cut rebuild time for LLVM is ccache. From owner-freebsd-ppc@freebsd.org Wed Apr 5 17:10:47 2017 Return-Path: Delivered-To: freebsd-ppc@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 28FE1D30D91; Wed, 5 Apr 2017 17:10:47 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (mx3.absolight.net [IPv6:2a01:678:2:100::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plouf.absolight.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D4EDFB23; Wed, 5 Apr 2017 17:10:46 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (localhost [127.0.0.1]) by prod2.absolight.net (Postfix) with ESMTP id 9FDCBBDCA4; Wed, 5 Apr 2017 19:10:43 +0200 (CEST) Received: from atuin.in.mat.cc (gw.in.spyou.org [79.143.241.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by prod2.absolight.net (Postfix) with ESMTPSA id 18B4CBDC91; Wed, 5 Apr 2017 19:10:43 +0200 (CEST) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) To: Alexey Dokuchaev , Matthew Rezny References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> <2502554.oHoOYGyFJH@workstation.reztek> <20170405161541.GA32323@FreeBSD.org> Cc: FreeBSD Current , Dimitry Andric , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Ports , Johannes M Dieterich , Mark Millard From: Mathieu Arnold Organization: Absolight / The FreeBSD Foundation Message-ID: <55bf3ea7-c601-ba55-822a-5b28cbca109f@FreeBSD.org> Date: Wed, 5 Apr 2017 19:12:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170405161541.GA32323@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WjAsUneJT7nd422H5VMBA6Mc4Ufb22fgn" X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 17:10:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WjAsUneJT7nd422H5VMBA6Mc4Ufb22fgn Content-Type: multipart/mixed; boundary="ni08C9tE33LjrPmq3SQ1sdiKLHT6lf9Eg"; protected-headers="v1" From: Mathieu Arnold To: Alexey Dokuchaev , Matthew Rezny Cc: FreeBSD Current , Dimitry Andric , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Ports , Johannes M Dieterich , Mark Millard Message-ID: <55bf3ea7-c601-ba55-822a-5b28cbca109f@FreeBSD.org> Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> <2502554.oHoOYGyFJH@workstation.reztek> <20170405161541.GA32323@FreeBSD.org> In-Reply-To: <20170405161541.GA32323@FreeBSD.org> --ni08C9tE33LjrPmq3SQ1sdiKLHT6lf9Eg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 05/04/2017 =C3=A0 18:15, Alexey Dokuchaev a =C3=A9crit : > On Thu, Mar 30, 2017 at 07:26:43PM +0200, Matthew Rezny wrote: >> LLVM 3.8 introduced the option to build a shared LLVM library, which i= s >> what Mesa needs for use at runtime (for e.g. compiling shaders), separ= ate >> from linking to it. Previous versions only had one option, if the libr= ary >> was built then all the LLVM binaries were staticly linked to it. [...]= >> >> llvm{35,36,37} are statically linked and thus smaller than normal. llv= m38 >> switched to dynamic linking, the default, thus the size grew. > Hmm, I don't quite get it: shouldn't static linking actually increase t= he > binaries (and thus the package) size? > >> I assume llvm40 will be a bit bigger, but do not expect to see another= >> jump as you've observed. > As Mark Millard reports: > >> I've also tried without WITH_DEBUG=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. > That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. So, you are comparing the size of the llvm39 package with the size of the llvm40 after extraction ? --=20 Mathieu Arnold --ni08C9tE33LjrPmq3SQ1sdiKLHT6lf9Eg-- --WjAsUneJT7nd422H5VMBA6Mc4Ufb22fgn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJY5SVnXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzQUI2OTc4OUQyRUQxMjEwNjQ0MEJBNUIz QTQ1MTZGMzUxODNDRTQ4AAoJEDpFFvNRg85IggoQAK4Wbi+nKIl9ewU5F0R5UgF5 CVSUw5VfMpmMNUXkBPEmUJnTJebjS0pKiM79ToRJLWpbMOkXdk44ge13SrXhOoVG 5IytzkQ3ArbyyogvFv24rYFHT/1H8faL45XWVJuEvBKjFKbOc+qgtdJDeudjhcAV PJBIgn651qMyrVfoE8ajiiErhPJjO0e8ROq9RKuiQuERQJ+TpAjSKI//Yi57mMig KVqbbFmPi6znpSdnAsVLmSppWSvyqWyeGF52HK5C+yxLRmCsHvoXgDRFX84jektb g9vEa8m3wJ4Sq7tqzzl3rKNyDSXgi/VWvxm5L0TkyxeIxy/Hr1gb3LW2hJqF4Ttm 1TDZ8EqCZ0WFxSGhFVPxKfXmXew7Y0XGFs0HVPXMzaoMAYufNPicu4O4kJIiJoFK KZM68Q8V4ggo+dk5zQiYb0J5t6SCBJgDJbo5/UFJNR5QTOVDg+7W8Rxc+LSON9XX HOEvbF8fgCJHPcZF1IPbcL3p773XsO14vlt9eXjaMP3zfSkonsP3TV0GCKXKE6jQ +EB3/bakWz6d05dkz85ZGF4KiO1gtnqFpVR1dnDCDAr322+9n1xUuYb0KSdVLAL2 QHdwO1WRPKdY7LWKceHUnVmuSpEaA3XRMbQo2KDXBAQwMxt43x8dIKlBCx5rAueb 6kEPYRNapRS8XHHuHR6n =/NWs -----END PGP SIGNATURE----- --WjAsUneJT7nd422H5VMBA6Mc4Ufb22fgn-- From owner-freebsd-ppc@freebsd.org Wed Apr 5 17:12:52 2017 Return-Path: Delivered-To: freebsd-ppc@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 D1011D30FAB; Wed, 5 Apr 2017 17:12:52 +0000 (UTC) (envelope-from rezny@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 B1E411EE; Wed, 5 Apr 2017 17:12:52 +0000 (UTC) (envelope-from rezny@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1406) id DF1934BB4; Wed, 5 Apr 2017 17:12:51 +0000 (UTC) From: Matthew Rezny To: Slawa Olhovchenkov , FreeBSD Current Cc: 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: Wed, 05 Apr 2017 19:12:51 +0200 Message-ID: <2580921.RCJsO5iqpA@workstation.reztek> Organization: FreeBSD User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20170405164451.GD20974@zxy.spb.ru> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <20170405161541.GA32323@FreeBSD.org> <20170405164451.GD20974@zxy.spb.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 17:12:52 -0000 On Wednesday 05 April 2017 19:44:51 Slawa Olhovchenkov wrote: > On Wed, Apr 05, 2017 at 04:15:41PM +0000, Alexey Dokuchaev wrote: > > > I've also tried without WITH_DEBUG= and now. . . > > > > > > # pkg delete llvm40 > > > Checking integrity... done (0 conflicting) > > > Deinstallation has been requested for the following 1 packages (of 0 > > > packages in the universe): > > > > > > Installed packages to be REMOVED: > > > llvm40-4.0.0 > > > > > > Number of packages to be removed: 1 > > > > > > The operation will free 1 GiB. > > > > That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. > > I'm surely looking forward modularization of LLVM port; rebuilding it > > every time becomes a real PITA given that X11 stack requires it. :-( > > What real reason of requiring llvm for X11? > I am about run time depends: > > # pkg info -r llvm39 > llvm39-3.9.1_4: > libEGL-13.0.6 > dri-13.0.6,2 > > # ldd /usr/local/lib/libXvMCr600.so > /usr/local/lib/libXvMCr600.so: > [...] > libLLVM-3.9.so => /usr/local/llvm39/lib/libLLVM-3.9.so (0x803e00000) > libLTO.so => /usr/local/llvm39/lib/../lib/libLTO.so (0x808200000) [...] > > # ls -lh /usr/local/llvm39/lib/libLLVM-3.9.so > /usr/local/llvm39/lib/../lib/libLTO.so -rwxr-xr-x 1 root wheel 38M Apr > 2 18:18 /usr/local/llvm39/lib/../lib/libLTO.so -rwxr-xr-x 1 root wheel > 47M Apr 2 18:18 /usr/local/llvm39/lib/libLLVM-3.9.so > > libXvMCr600 realy do run-time llvm interpetation and linker-time > optimisation?! > > Also, I am don't see any realy dependence libEGL-13.0.6 from llvm. Yes, Mesa really uses LLVM at runtime for shader compilation/optimization, and Xorg depends on Mesa for GLX, etc. From owner-freebsd-ppc@freebsd.org Wed Apr 5 17:20:55 2017 Return-Path: Delivered-To: freebsd-ppc@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 1503AD304F6; Wed, 5 Apr 2017 17:20:55 +0000 (UTC) (envelope-from danfe@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 E6C04D8B; Wed, 5 Apr 2017 17:20:54 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 1916150FC; Wed, 5 Apr 2017 17:20:54 +0000 (UTC) Date: Wed, 5 Apr 2017 17:20:54 +0000 From: Alexey Dokuchaev To: Mathieu Arnold Cc: Matthew Rezny , FreeBSD Current , Dimitry Andric , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Ports , Johannes M Dieterich , Mark Millard 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: <20170405172054.GB32323@FreeBSD.org> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> <2502554.oHoOYGyFJH@workstation.reztek> <20170405161541.GA32323@FreeBSD.org> <55bf3ea7-c601-ba55-822a-5b28cbca109f@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55bf3ea7-c601-ba55-822a-5b28cbca109f@FreeBSD.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 17:20:55 -0000 On Wed, Apr 05, 2017 at 07:12:06PM +0200, Mathieu Arnold wrote: > Le 05/04/2017 ?? 18:15, Alexey Dokuchaev a ??crit : > > ... > > That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. > > So, you are comparing the size of the llvm39 package with the size of > the llvm40 after extraction ? Ha, didn't realize it, I'm so dumb. What the size of llvm40-*.txz then? I don't have it cached locally yet... ./danfe From owner-freebsd-ppc@freebsd.org Wed Apr 5 18:46:28 2017 Return-Path: Delivered-To: freebsd-ppc@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 E6876D30954; Wed, 5 Apr 2017 18:46:28 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (prod2.absolight.net [79.143.243.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plouf.absolight.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8093483E; Wed, 5 Apr 2017 18:46:28 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from prod2.absolight.net (localhost [127.0.0.1]) by prod2.absolight.net (Postfix) with ESMTP id 5E1ABBDC9F; Wed, 5 Apr 2017 20:46:25 +0200 (CEST) Received: from atuin.in.mat.cc (gw.in.spyou.org [79.143.241.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by prod2.absolight.net (Postfix) with ESMTPSA id 86A2CBDC91; Wed, 5 Apr 2017 20:46:24 +0200 (CEST) Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) To: Alexey Dokuchaev References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> <2502554.oHoOYGyFJH@workstation.reztek> <20170405161541.GA32323@FreeBSD.org> <55bf3ea7-c601-ba55-822a-5b28cbca109f@FreeBSD.org> <20170405172054.GB32323@FreeBSD.org> Cc: Matthew Rezny , FreeBSD Current , Dimitry Andric , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Ports , Johannes M Dieterich , Mark Millard From: Mathieu Arnold Organization: Absolight / The FreeBSD Foundation Message-ID: Date: Wed, 5 Apr 2017 20:46:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170405172054.GB32323@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Q0QVOeJgRj33QQfHPwlTqfGT51VPIUAGb" X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 18:46:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Q0QVOeJgRj33QQfHPwlTqfGT51VPIUAGb Content-Type: multipart/mixed; boundary="1enJNnr6oVq91hkVKPtf3LOhMehbwrbEo"; protected-headers="v1" From: Mathieu Arnold To: Alexey Dokuchaev Cc: Matthew Rezny , FreeBSD Current , Dimitry Andric , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Ports , Johannes M Dieterich , Mark Millard Message-ID: Subject: Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example) References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> <2502554.oHoOYGyFJH@workstation.reztek> <20170405161541.GA32323@FreeBSD.org> <55bf3ea7-c601-ba55-822a-5b28cbca109f@FreeBSD.org> <20170405172054.GB32323@FreeBSD.org> In-Reply-To: <20170405172054.GB32323@FreeBSD.org> --1enJNnr6oVq91hkVKPtf3LOhMehbwrbEo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 05/04/2017 =C3=A0 19:20, Alexey Dokuchaev a =C3=A9crit : > On Wed, Apr 05, 2017 at 07:12:06PM +0200, Mathieu Arnold wrote: >> Le 05/04/2017 ?? 18:15, Alexey Dokuchaev a ??crit : >>> ... >>> That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. >> So, you are comparing the size of the llvm39 package with the size of >> the llvm40 after extraction ? > Ha, didn't realize it, I'm so dumb. What the size of llvm40-*.txz then= ? > I don't have it cached locally yet... On my builds: -rw-r--r-- 6 nobody wheel 256105968 4 avr. 17:54 llvm39-3.9.1_4.txz -rw-r--r-- 6 nobody wheel 304951340 4 avr. 18:02 llvm40-4.0.0_2.txz --=20 Mathieu Arnold --1enJNnr6oVq91hkVKPtf3LOhMehbwrbEo-- --Q0QVOeJgRj33QQfHPwlTqfGT51VPIUAGb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJY5Tt/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzQUI2OTc4OUQyRUQxMjEwNjQ0MEJBNUIz QTQ1MTZGMzUxODNDRTQ4AAoJEDpFFvNRg85IapEQAISBsfrnx/eyHjhbB29/E8+Y NWYUjkmSfE4dzO2e2vR3zl22gj6k2WU5IWTBktMCaBcGUfeTERdkPC8rx+aHQHWs NjRJo0NPUFv978yyl3r8cluOw7UdUZi6vPRUglEqYtfr7TPtjJBVv7J5KYLzqFfO TINAXFr/9L01q4Z5qdcy5wWOFsOj30Y1Jvslw58vZXVc+aE92NnjejB3EPs6MLuD V4AkKBMxxm6QreAhJZyRcVvPJFkvR/1EX9hdIbtj7BMkUz/KiQtU/GrsPzz2Ghct NI2ijpv90K1m1AOJX6I9twX+tG7u+PPnJEtSSGet6tlb+TcKlItOLB7/VvSo7NBd 7lIOOIN3EF6Y27j6fvEjD+qgY2QWox8KigC0uGBbAq6aBaL0cy0Cf4pLkB5G1/dT 80N2GR40zeKI5dl+dXV3N4OGpBp1DdudS0P7uopdq/JNWBU2AD5umc7LpW8r/4Y9 j7xPWtFBCMwqWqI1rN6tE6ZDYT8sKuNPQ9saVYdzoCmODmjWY42iW4t8Q479VXRV q6O+xPQk8jhjfwdwuve5yhDjXa7OpBsdKwn2Xz3N1TuPyIGdqX9PdDpkySKXVCIA JgL4AWxHddEysL+GksCq3MXsVaPmVaXlw9f/55yNIjxM6WSmdwQClR3ig6wf0WH5 rfgpHwi33ZBuTm5ijdL8 =8RZZ -----END PGP SIGNATURE----- --Q0QVOeJgRj33QQfHPwlTqfGT51VPIUAGb-- From owner-freebsd-ppc@freebsd.org Wed Apr 5 22:22:24 2017 Return-Path: Delivered-To: freebsd-ppc@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 1C7E3D305F4 for ; Wed, 5 Apr 2017 22:22:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-84.reflexion.net [208.70.210.84]) (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 BE505B90 for ; Wed, 5 Apr 2017 22:22:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3476 invoked from network); 5 Apr 2017 22:16:40 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 Apr 2017 22:16:40 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Wed, 05 Apr 2017 18:15:42 -0400 (EDT) Received: (qmail 10856 invoked from network); 5 Apr 2017 22:15:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Apr 2017 22:15:42 -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 805F0EC8172; Wed, 5 Apr 2017 15:15:41 -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: <20170405172054.GB32323@FreeBSD.org> Date: Wed, 5 Apr 2017 15:15:40 -0700 Cc: Mathieu Arnold , Matthew Rezny , FreeBSD Current , Dimitry Andric , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Ports , Johannes M Dieterich Content-Transfer-Encoding: 7bit Message-Id: References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> <2502554.oHoOYGyFJH@workstation.reztek> <20170405161541.GA32323@FreeBSD.org> <55bf3ea7-c601-ba55-822a-5b28cbca109f@FreeBSD.org> <20170405172054.GB32323@FreeBSD.org> To: Alexey Dokuchaev X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 22:22:24 -0000 On 2017-Apr-5, at 10:20 AM, Alexey Dokuchaev wrote: > On Wed, Apr 05, 2017 at 07:12:06PM +0200, Mathieu Arnold wrote: >> Le 05/04/2017 ?? 18:15, Alexey Dokuchaev a ??crit : >>> ... >>> That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. >> >> So, you are comparing the size of the llvm39 package with the size of >> the llvm40 after extraction ? > > Ha, didn't realize it, I'm so dumb. What the size of llvm40-*.txz then? > I don't have it cached locally yet... Someone else provided a comparison. But as for the installed-size goes: Looks like pkg delete's report of size is truncated or rounded to an integral GiByte count for llvm40. pkg info shows (reminder: powerpc64 context): # pkg info llvm40 | grep "Flat size" Flat size : 1.38GiB So I did not pick a good estimate to report for installed-size for the no-WITH_DEBUG variant's scale for installed-size. === Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Thu Apr 6 11:02:04 2017 Return-Path: Delivered-To: freebsd-ppc@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 67A22D31DE4; Thu, 6 Apr 2017 11:02:04 +0000 (UTC) (envelope-from danfe@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 4360DADB; Thu, 6 Apr 2017 11:02:04 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 6A0352E73; Thu, 6 Apr 2017 11:02:03 +0000 (UTC) Date: Thu, 6 Apr 2017 11:02:03 +0000 From: Alexey Dokuchaev To: Mathieu Arnold Cc: Matthew Rezny , FreeBSD Current , Dimitry Andric , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Ports , Johannes M Dieterich , Mark Millard 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: <20170406110203.GA83987@FreeBSD.org> References: <3EDEF0B7-59C5-4648-9737-6682E18645BC@dsl-only.net> <7F94CE59-D2CC-4D6F-B1CD-FF3D1F8EDCE7@FreeBSD.org> <20170330170648.GA38004@FreeBSD.org> <2502554.oHoOYGyFJH@workstation.reztek> <20170405161541.GA32323@FreeBSD.org> <55bf3ea7-c601-ba55-822a-5b28cbca109f@FreeBSD.org> <20170405172054.GB32323@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 11:02:04 -0000 On Wed, Apr 05, 2017 at 08:46:22PM +0200, Mathieu Arnold wrote: > Le 05/04/2017 ?? 19:20, Alexey Dokuchaev a ??crit : > > On Wed, Apr 05, 2017 at 07:12:06PM +0200, Mathieu Arnold wrote: > >> Le 05/04/2017 ?? 18:15, Alexey Dokuchaev a ??crit : > >>> ... > >>> That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. > >> > >> So, you are comparing the size of the llvm39 package with the size of > >> the llvm40 after extraction ? > > > > Ha, didn't realize it, I'm so dumb. What [is] the size of llvm40-*.txz > > then? I don't have it cached locally yet... > > On my builds: > > -rw-r--r-- 6 nobody wheel 256105968 4 avr. 17:54 llvm39-3.9.1_4.txz > -rw-r--r-- 6 nobody wheel 304951340 4 avr. 18:02 llvm40-4.0.0_2.txz Thanks, now it all makes sense, sorry for confusion. ./danfe