From owner-freebsd-toolchain@freebsd.org Sun Jul 2 01:53:42 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 2BC28D981F7 for ; Sun, 2 Jul 2017 01:53:42 +0000 (UTC) (envelope-from sid@bsdmail.com) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mail.gmx.com", Issuer "thawte SSL CA - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB54D7A0F5 for ; Sun, 2 Jul 2017 01:53:41 +0000 (UTC) (envelope-from sid@bsdmail.com) Received: from [108.70.50.7] by 3capp-mailcom-lxa04.server.lan (via HTTP); Sun, 2 Jul 2017 03:53:34 +0200 MIME-Version: 1.0 Message-ID: From: Sid To: freebsd-toolchain@freebsd.org Subject: Re: suggestion for toolchain to have its own directories Content-Type: text/plain; charset=UTF-8 Date: Sun, 2 Jul 2017 03:53:34 +0200 Importance: normal Sensitivity: Normal Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-Provags-ID: V03:K1:cbC3V3T9F7ePnF2cYmxj9d82YNdh4i6yJVzOmvDSDKl whtuPSgGGcLK94v0KI24DwKlybJzQFvhR85+hbHcJGhA4c7u2A wo2J02SPahweKZMkvZX5uEEU5ydDyUVXGFlvb6axeaxhZ+lh2r o63PZApz/1GV9T2o56t67XoARu4OHAkr/nbu7Lk0ibQT684cVZ y+QnVEId+i5K3ujQ+7zOEVTlCKPZNPnKoMvZVW8qoUfF/AJl79 YH4F91TY/lSOa9yfanE85Ogy7DeCRXsMVI2uPIcz4K5lddV+XJ G2shuz+98eNIIh/EK/jjrlQqKeX X-UI-Out-Filterresults: notjunk:1;V01:K0:xghnZ8K46wo=:F4yUtpHKiO41UR4rooLixO OvT16HRbJ0YZzOC+iBOUMm/iJM4FTv07lBmEmJ8F6DJ854nLXgySg81M4WGDg18vSuQCSRpeY ny2bd3e/NqqZ5BBnV+lfFRCerQJ7LD3iVdptaWKjt0L2ohGhMJVPkSe0WWcs7PNXbXQrl7LfU JbglGRIz1Cd2cMLOr4IBJsjUvsQ5CtwJah85ZWre4UI3XeGQD/rco28N8Gk7aT0vQ0mMk+n3f aONpt1SPIyf8nTfPEdQvr3fgXsgAYcUB9CeiITiz91P10VWAQ6gYcIiH5lsMC7zpuR+yV9icm 3OFJiOqe82nVRnxQbdvupK058aDL3/yFD29ifutqwdLT8KLf6VvkyJTesIfWITSEifU04M2+r 72WweasF0BzGeRmMqxm7jX2Mewz7x0Dq1fV/bzd86K2NvW2lHmyCcZJSVg4NoXL7CEYJJBeGA mwBj0jpOew8QnHPK9udXIXNfPGiFPQhyQMfudb4Vui30LjqA5gLrjLUQNJ+JJ2kfcovxxHW6d ODeOrSbni0TjYs+4jFDI0M= 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, 02 Jul 2017 01:53:42 -0000 Any drastic change would have to be done in the head branch=2E What about keeping ports' compilers as they are, by not using /usr/local/t= oolchain/* at all=2E Then going with the directory for the base system=2E For instance: /usr/to= olchain/bin/, /usr/toolchain/sbin/, and /usr/toolchain/lib/ for shared file= s=2E Then using /usr/toolchain/clang/ and /usr/toolchain/gcc/ for specifica= lly needed files? of course the directory name can be abbreviated or otherw= ise shortened=2E This suggestion is kind of like the include/ directories= =2E If that's more difficult then, I'll redact my argument=2E In a way it s= hould be more organized=2E However, in another way, perhaps it is more upke= ep, which I intended to propose the opposite effect=2E Fri Jun 30 21:13:32 UTC 2017, Mark Millard wrot= e: >There is some commonality=2E Both contexts are based on >earlier Unix and Unix-like hierarchies=2E And the >commonality helps with making ports and such easier >to support as an example=2E The types of systems are not >completely independent=2E >Lots of tools and such are based on knowing current >placements and general properties of the hierarchies=2E >Reorganizations are a big deal and do not happen >often=2E >It is also messy for ports to organize things differently >than upstream does=2E So things like lang/gcc7-devel are >unlikely to go to the effort of being significantly >different when the commonality covers most of the >placements already (at least for default configurations)=2E Sat Jul 1 10:01:29 UTC 2017, David Chisnall wr= ote: >Debian does something like this, and it=E2=80=99s a huge pain to work wit= h=2E The problem is that toolchains are not self-contained >monolithic com= ponents (though gcc likes to pretend that they are)=2E For example, we wan= t gcc and clang to use the same >linker, the same C and C++ standard librar= y implementations, and the same system headers, irrespective of the compile= r >version=2E Things that actually are private to a compiler are in separa= te directories (see /usr/lib/clang, for example)=2E >David From owner-freebsd-toolchain@freebsd.org Mon Jul 3 02:54:09 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 005459DC1D0 for ; Mon, 3 Jul 2017 02:54:09 +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 9D9F27EB72 for ; Mon, 3 Jul 2017 02:54:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6088 invoked from network); 3 Jul 2017 02:55:32 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 3 Jul 2017 02:55:32 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sun, 02 Jul 2017 22:54:01 -0400 (EDT) Received: (qmail 31557 invoked from network); 3 Jul 2017 02:54:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Jul 2017 02:54:01 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6ADB8EC8171; Sun, 2 Jul 2017 19:54:00 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: It looks like USE_GCC=any is broken and leads to system-clang use Date: Sun, 2 Jul 2017 19:53:59 -0700 References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> To: Gerald Pfeifer , FreeBSD Ports , FreeBSD Toolchain In-Reply-To: Message-Id: <8F50FB7C-498C-453E-AE5A-EADC60758730@dsl-only.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: Mon, 03 Jul 2017 02:54:09 -0000 [It looks like USE_GCC=3Dany is broken and leads to system-clang use.] On 2017-Jun-29, at 5:58 PM, Gerald Pfeifer = wrote: > Am 29. Juni 2017 18:55:59 GMT+08:00 schrieb Mark Millard = : >> I'm not currently set up to run more than head on >> any of amd64, powerpc64, powerpc, aarch64, or armv6/7 >> (which are all I target). And I'm in the middle of >> attempting a fairly large jump to head -r320458 on >> those. >=20 > Oh, then I had misunderstood your previous mail. No worries, I'll = gently proceed then. >=20 > I expect to update gcc5 in the next 24 hours. >=20 >> [In my normal/head environment I'm switching to lang/gcc7-devel >> for gcc (from lang/gcc6 ) but I'm odd that way.] >=20 > The compiler should be fine, it's a number of ports that are not (even = blocking the move from GCC 5 to 6 as default). As part of testing that an environment seemed stable, an environment based on head -r320570 and ports -r444872 with gcc being lang/gcc7-devel that is installed on amd64, I tried: script ~/ports_typescripts/phoronix-try-00-typescript portmaster -DK = benchmarks/phoronix-test-suite in part because it has: USE_GCC=3D any and I'm using: DEFAULT_VERSIONS+=3Dperl5=3D5.24 gcc=3D7 in /etc/make.conf and the gcc that I have installed is lang/gcc7-devel. This should also have been a test of the adjusted-header removal that has been applied to lang/gcc7-devel (but not a old environment's build used under a modern system environment). But the result was a surprise: the log file shows all the build as using cc and in my context cc is: # cc --version FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin Configure repeatedly shows: checking for gcc... cc . . . checking whether we are using the GNU C compiler... yes In fact "phoronix-test-suite diagnostics" reports: COMPILER =3D Clang 4.0.0 (SVN 297347) + LLVM 4.0.0 So clang is being treated as an example of gcc as far as I can tell. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Jul 3 03:12:16 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 EC38C9DC5AC for ; Mon, 3 Jul 2017 03:12:16 +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 A96CD7F69A for ; Mon, 3 Jul 2017 03:12:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22157 invoked from network); 3 Jul 2017 03:16:32 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 3 Jul 2017 03:16:32 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sun, 02 Jul 2017 23:12:15 -0400 (EDT) Received: (qmail 11465 invoked from network); 3 Jul 2017 03:12:14 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Jul 2017 03:12:14 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 42744EC8171; Sun, 2 Jul 2017 20:12:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: It looks like USE_GCC=any is broken and leads to system-clang use From: Mark Millard In-Reply-To: <8F50FB7C-498C-453E-AE5A-EADC60758730@dsl-only.net> Date: Sun, 2 Jul 2017 20:12:13 -0700 Cc: FreeBSD Ports , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> <8F50FB7C-498C-453E-AE5A-EADC60758730@dsl-only.net> To: Gerald Pfeifer 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: Mon, 03 Jul 2017 03:12:17 -0000 [Looks like output from "make test-gcc" is appropriate, so I'm adding such.] On 2017-Jul-2, at 7:53 PM, Mark Millard wrote: > [It looks like USE_GCC=3Dany is broken and leads to system-clang use.] >=20 > On 2017-Jun-29, at 5:58 PM, Gerald Pfeifer = wrote: >=20 >> Am 29. Juni 2017 18:55:59 GMT+08:00 schrieb Mark Millard = : >>> I'm not currently set up to run more than head on >>> any of amd64, powerpc64, powerpc, aarch64, or armv6/7 >>> (which are all I target). And I'm in the middle of >>> attempting a fairly large jump to head -r320458 on >>> those. >>=20 >> Oh, then I had misunderstood your previous mail. No worries, I'll = gently proceed then. >>=20 >> I expect to update gcc5 in the next 24 hours. >>=20 >>> [In my normal/head environment I'm switching to lang/gcc7-devel >>> for gcc (from lang/gcc6 ) but I'm odd that way.] >>=20 >> The compiler should be fine, it's a number of ports that are not = (even blocking the move from GCC 5 to 6 as default). >=20 > As part of testing that an environment seemed stable, > an environment based on head -r320570 and ports -r444872 > with gcc being lang/gcc7-devel that is installed on > amd64, I tried: >=20 > script ~/ports_typescripts/phoronix-try-00-typescript portmaster -DK = benchmarks/phoronix-test-suite >=20 > in part because it has: >=20 > USE_GCC=3D any >=20 > and I'm using: >=20 > DEFAULT_VERSIONS+=3Dperl5=3D5.24 gcc=3D7 >=20 > in /etc/make.conf and the gcc that I have installed > is lang/gcc7-devel. This should also have been a test > of the adjusted-header removal that has been applied > to lang/gcc7-devel (but not a old environment's build > used under a modern system environment). >=20 > But the result was a surprise: the log file > shows all the build as using cc and in my context > cc is: >=20 > # cc --version > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) > Target: x86_64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin >=20 > Configure repeatedly shows: >=20 > checking for gcc... cc > . . . > checking whether we are using the GNU C compiler... yes >=20 >=20 > In fact "phoronix-test-suite diagnostics" reports: >=20 > COMPILER =3D Clang 4.0.0 (SVN 297347) + LLVM 4.0.0 >=20 > So clang is being treated as an example of gcc as far > as I can tell. # cd /usr/ports/benchmarks/phoronix-test-suite/ FreeBSDx64OPC# make test-gcc USE_GCC=3Dany Port can use later versions. GCC version: 4.2 - OSVERSION up to 9999999 GCC version: 4.8 - OSVERSION up to 0 GCC version: 4.9 - OSVERSION up to 0 GCC version: 5 - OSVERSION up to 0 GCC version: 6 - OSVERSION up to 0 Using GCC version 7 CC=3Dcc - CXX=3Dc++ - CPP=3Dcpp - CFLAGS=3D"-O2 -pipe -g = -fstack-protector -fno-strict-aliasing" LDFLAGS=3D" -fstack-protector" BUILD_DEPENDS=3D/usr/local/include/php/main/php.h:lang/php56 = /usr/local/bin/python2.7:lang/python27 = update-desktop-database:devel/desktop-file-utils = update-mime-database:misc/shared-mime-info = /usr/local/lib/php/20131226/ctype.so:textproc/php56-ctype = /usr/local/lib/php/20131226/curl.so:ftp/php56-curl = /usr/local/lib/php/20131226/dom.so:textproc/php56-dom = /usr/local/lib/php/20131226/filter.so:security/php56-filter = /usr/local/lib/php/20131226/gd.so:graphics/php56-gd = /usr/local/lib/php/20131226/hash.so:security/php56-hash = /usr/local/lib/php/20131226/json.so:devel/php56-json = /usr/local/lib/php/20131226/openssl.so:security/php56-openssl = /usr/local/lib/php/20131226/pcntl.so:devel/php56-pcntl = /usr/local/lib/php/20131226/posix.so:sysutils/php56-posix = /usr/local/lib/php/20131226/session.so:www/php56-session = /usr/local/lib/php/20131226/simplexml.so:textproc/php56-simplexml = /usr/local/lib/php/20131226/sockets.so:net/php56-sockets = /usr/local/lib/php/20131226/sqlite3.so:databases/php56-sqlite3 = /usr/local/lib/php/20131226/zip.so:archivers/php56-zip = /usr/local/lib/php/20131226/zlib.so:archivers/php56-zlib RUN_DEPENDS=3Dfpdf>0:print/fpdf cmake:devel/cmake = /usr/local/include/php/main/php.h:lang/php56 = /usr/local/bin/python2.7:lang/python27 = update-desktop-database:devel/desktop-file-utils = update-mime-database:misc/shared-mime-info = /usr/local/lib/php/20131226/ctype.so:textproc/php56-ctype = /usr/local/lib/php/20131226/curl.so:ftp/php56-curl = /usr/local/lib/php/20131226/dom.so:textproc/php56-dom = /usr/local/lib/php/20131226/filter.so:security/php56-filter = /usr/local/lib/php/20131226/gd.so:graphics/php56-gd = /usr/local/lib/php/20131226/hash.so:security/php56-hash = /usr/local/lib/php/20131226/json.so:devel/php56-json = /usr/local/lib/php/20131226/openssl.so:security/php56-openssl = /usr/local/lib/php/20131226/pcntl.so:devel/php56-pcntl = /usr/local/lib/php/20131226/posix.so:sysutils/php56-posix = /usr/local/lib/php/20131226/session.so:www/php56-session = /usr/local/lib/php/20131226/simplexml.so:textproc/php56-simplexml = /usr/local/lib/php/20131226/sockets.so:net/php56-sockets = /usr/local/lib/php/20131226/sqlite3.so:databases/php56-sqlite3 = /usr/local/lib/php/20131226/zip.so:archivers/php56-zip = /usr/local/lib/php/20131226/zlib.so:archivers/php56-zlib =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Jul 3 05:30:16 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 D50169DE5BC for ; Mon, 3 Jul 2017 05:30:16 +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 9799C82B35 for ; Mon, 3 Jul 2017 05:30:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28153 invoked from network); 3 Jul 2017 05:30:15 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 3 Jul 2017 05:30:15 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Mon, 03 Jul 2017 01:30:15 -0400 (EDT) Received: (qmail 29639 invoked from network); 3 Jul 2017 05:30:14 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Jul 2017 05:30:14 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 07F1AEC7C08; Sun, 2 Jul 2017 22:30:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: It looks like USE_GCC=any is broken and leads to system-clang use From: Mark Millard In-Reply-To: Date: Sun, 2 Jul 2017 22:30:13 -0700 Cc: FreeBSD Toolchain , FreeBSD Ports Content-Transfer-Encoding: quoted-printable Message-Id: <1BFFF3BD-7658-452F-9369-7C2AED479FB6@dsl-only.net> References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> <8F50FB7C-498C-453E-AE5A-EADC60758730@dsl-only.net> To: Gerald Pfeifer 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: Mon, 03 Jul 2017 05:30:16 -0000 [More on the behavior: it is more complicated than previously shown.] On 2017-Jul-2, at 8:12 PM, Mark Millard wrote: > [Looks like output from "make test-gcc" is appropriate, > so I'm adding such.] >=20 > On 2017-Jul-2, at 7:53 PM, Mark Millard = wrote: >=20 >> [It looks like USE_GCC=3Dany is broken and leads to system-clang = use.] >>=20 >> On 2017-Jun-29, at 5:58 PM, Gerald Pfeifer = wrote: >>=20 >>> Am 29. Juni 2017 18:55:59 GMT+08:00 schrieb Mark Millard = : >>>> I'm not currently set up to run more than head on >>>> any of amd64, powerpc64, powerpc, aarch64, or armv6/7 >>>> (which are all I target). And I'm in the middle of >>>> attempting a fairly large jump to head -r320458 on >>>> those. >>>=20 >>> Oh, then I had misunderstood your previous mail. No worries, I'll = gently proceed then. >>>=20 >>> I expect to update gcc5 in the next 24 hours. >>>=20 >>>> [In my normal/head environment I'm switching to lang/gcc7-devel >>>> for gcc (from lang/gcc6 ) but I'm odd that way.] >>>=20 >>> The compiler should be fine, it's a number of ports that are not = (even blocking the move from GCC 5 to 6 as default). >>=20 >> As part of testing that an environment seemed stable, >> an environment based on head -r320570 and ports -r444872 >> with gcc being lang/gcc7-devel that is installed on >> amd64, I tried: >>=20 >> script ~/ports_typescripts/phoronix-try-00-typescript portmaster -DK = benchmarks/phoronix-test-suite >>=20 >> in part because it has: >>=20 >> USE_GCC=3D any >>=20 >> and I'm using: >>=20 >> DEFAULT_VERSIONS+=3Dperl5=3D5.24 gcc=3D7 >>=20 >> in /etc/make.conf and the gcc that I have installed >> is lang/gcc7-devel. This should also have been a test >> of the adjusted-header removal that has been applied >> to lang/gcc7-devel (but not a old environment's build >> used under a modern system environment). >>=20 >> But the result was a surprise: the log file >> shows all the build as using cc and in my context >> cc is: >>=20 >> # cc --version >> FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) >> Target: x86_64-unknown-freebsd12.0 >> Thread model: posix >> InstalledDir: /usr/bin >>=20 >> Configure repeatedly shows: >>=20 >> checking for gcc... cc >> . . . >> checking whether we are using the GNU C compiler... yes >>=20 >>=20 >> In fact "phoronix-test-suite diagnostics" reports: >>=20 >> COMPILER =3D Clang 4.0.0 (SVN 297347) + LLVM 4.0.0 >>=20 >> So clang is being treated as an example of gcc as far >> as I can tell. >=20 > # cd /usr/ports/benchmarks/phoronix-test-suite/ > FreeBSDx64OPC# make test-gcc > USE_GCC=3Dany > Port can use later versions. > GCC version: 4.2 - OSVERSION up to 9999999 > GCC version: 4.8 - OSVERSION up to 0 > GCC version: 4.9 - OSVERSION up to 0 > GCC version: 5 - OSVERSION up to 0 > GCC version: 6 - OSVERSION up to 0 > Using GCC version 7 > CC=3Dcc - CXX=3Dc++ - CPP=3Dcpp - CFLAGS=3D"-O2 -pipe -g = -fstack-protector -fno-strict-aliasing" > LDFLAGS=3D" -fstack-protector" > BUILD_DEPENDS=3D/usr/local/include/php/main/php.h:lang/php56 = /usr/local/bin/python2.7:lang/python27 = update-desktop-database:devel/desktop-file-utils = update-mime-database:misc/shared-mime-info = /usr/local/lib/php/20131226/ctype.so:textproc/php56-ctype = /usr/local/lib/php/20131226/curl.so:ftp/php56-curl = /usr/local/lib/php/20131226/dom.so:textproc/php56-dom = /usr/local/lib/php/20131226/filter.so:security/php56-filter = /usr/local/lib/php/20131226/gd.so:graphics/php56-gd = /usr/local/lib/php/20131226/hash.so:security/php56-hash = /usr/local/lib/php/20131226/json.so:devel/php56-json = /usr/local/lib/php/20131226/openssl.so:security/php56-openssl = /usr/local/lib/php/20131226/pcntl.so:devel/php56-pcntl = /usr/local/lib/php/20131226/posix.so:sysutils/php56-posix = /usr/local/lib/php/20131226/session.so:www/php56-session = /usr/local/lib/php/20131226/simplexml.so:textproc/php56-simplexml = /usr/local/lib/php/20131226/sockets.so:net/php56-sockets = /usr/local/lib/php/20131226/sqlite3.so:databases/php56-sqlite3 /usr/l > ocal/lib/php/20131226/zip.so:archivers/php56-zip = /usr/local/lib/php/20131226/zlib.so:archivers/php56-zlib > RUN_DEPENDS=3Dfpdf>0:print/fpdf cmake:devel/cmake = /usr/local/include/php/main/php.h:lang/php56 = /usr/local/bin/python2.7:lang/python27 = update-desktop-database:devel/desktop-file-utils = update-mime-database:misc/shared-mime-info = /usr/local/lib/php/20131226/ctype.so:textproc/php56-ctype = /usr/local/lib/php/20131226/curl.so:ftp/php56-curl = /usr/local/lib/php/20131226/dom.so:textproc/php56-dom = /usr/local/lib/php/20131226/filter.so:security/php56-filter = /usr/local/lib/php/20131226/gd.so:graphics/php56-gd = /usr/local/lib/php/20131226/hash.so:security/php56-hash = /usr/local/lib/php/20131226/json.so:devel/php56-json = /usr/local/lib/php/20131226/openssl.so:security/php56-openssl = /usr/local/lib/php/20131226/pcntl.so:devel/php56-pcntl = /usr/local/lib/php/20131226/posix.so:sysutils/php56-posix = /usr/local/lib/php/20131226/session.so:www/php56-session = /usr/local/lib/php/20131226/simplexml.so:textproc/php56-simplexml = /usr/local/lib/php/20131226/sockets.so:net/php56-sockets = /usr/local/lib/php/20131226/sqlite3 > .so:databases/php56-sqlite3 = /usr/local/lib/php/20131226/zip.so:archivers/php56-zip = /usr/local/lib/php/20131226/zlib.so:archivers/php56-zlib I used: Index: /usr/ports/Mk/bsd.gcc.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.gcc.mk (revision 444872) +++ /usr/ports/Mk/bsd.gcc.mk (working copy) @@ -35,7 +35,7 @@ # ascending order and in sync with the table below.=20 # When adding a version, please keep the comment in # Mk/bsd.default-versions.mk in sync. -GCCVERSIONS=3D 040200 040800 040900 050000 060000 +GCCVERSIONS=3D 040200 040800 040900 050000 060000 070000 =20 # The first field is the OSVERSION in which it disappeared from the = base. # The second field is the version as USE_GCC would use. @@ -44,6 +44,7 @@ GCCVERSION_040900=3D 0 4.9 GCCVERSION_050000=3D 0 5 GCCVERSION_060000=3D 0 6 +GCCVERSION_070000=3D 0 7 =20 # No configurable parts below this. = #################################### # to get "make test-gcc" to report: # pwd /usr/ports/benchmarks/phoronix-test-suite FreeBSDx64OPC# make test-gcc USE_GCC=3Dany Port can use later versions. GCC version: 4.2 - OSVERSION up to 9999999 GCC version: 4.8 - OSVERSION up to 0 GCC version: 4.9 - OSVERSION up to 0 GCC version: 5 - OSVERSION up to 0 GCC version: 6 - OSVERSION up to 0 GCC version: 7 (port) - OSVERSION up to 0 Using GCC version 7 CC=3Dgcc7 - CXX=3Dg++7 - CPP=3Dcpp7 - CFLAGS=3D"-O2 -pipe -g = -fstack-protector -Wl,-rpath=3D/usr/local/lib/gcc7 -fno-strict-aliasing" LDFLAGS=3D" -fstack-protector -Wl,-rpath=3D/usr/local/lib/gcc7 = -L/usr/local/lib/gcc7" . . . But uninstalling and reinstalling still ended up with configure using "cc" (system clang) as a gcc compiler, despite what the ports infrastructure reported (shown above). So phoronix-test-suite ends up using clang to compile benchmarks unless one adjusts install.sh scripts manually and then uses the adjusted script to rebuild code. [I only tried: "phoronix-test-suite benchmark pts/hint" .] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Jul 3 11:21: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 726209E452B for ; Mon, 3 Jul 2017 11:21:21 +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 25199683A4 for ; Mon, 3 Jul 2017 11:21:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24025 invoked from network); 3 Jul 2017 11:21:19 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 3 Jul 2017 11:21:19 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Mon, 03 Jul 2017 07:21:19 -0400 (EDT) Received: (qmail 25295 invoked from network); 3 Jul 2017 11:21:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Jul 2017 11:21:18 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2AEDAEC8143; Mon, 3 Jul 2017 04:21:18 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r320570 (e.g.): ld crashes on powerpc64. . . (this was during port builds, I got about 65 of them) Message-Id: <39759CC6-03A4-4041-8B2C-93E030E733AB@dsl-only.net> Date: Mon, 3 Jul 2017 04:21:17 -0700 To: FreeBSD Toolchain , FreeBSD PowerPC ML 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: Mon, 03 Jul 2017 11:21:21 -0000 Using one of the examples for illustration of what is common to each that I've looked at: Core was generated by `/usr/bin/ld --eh-frame-hdr -Bstatic -o conftest = /usr/lib/crt1.o /usr/lib/crti.o'. Program terminated with signal 11, Segmentation fault. #0 0x000000001002dc78 in .text () (gdb) bt #0 0x000000001002dc78 in .text () #1 0x000000001000101c in ppc_before_allocation () at = eelf64ppc_fbsd.c:204 #2 0x0000000010009a2c in ldemul_before_allocation () at = /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldemul.c:= 78 #3 0x0000000010017844 in lang_process () at = /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldlang.c:= 5785 #4 0x00000000100219b0 in main (argc=3D0, argv=3D) = at = /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmain.c:= 459 #5 0x000000001000049c in .text () #1 source around eelf64ppc_fbsd.c:204 being: 199 TLS segment layout so that certain optimizations = can be done. */ 200 expld.phase =3D lang_mark_phase_enum; 201 expld.dataseg.phase =3D exp_dataseg_none; 202 one_lang_size_sections_pass (NULL, TRUE); 203=09 204 if (!ppc64_elf_tls_optimize (output_bfd, &link_info)) 205 einfo ("%X%P: TLS problem %E\n"); 206=09 207 /* We must not cache anything from the preliminary = sizing. */ 208 lang_reset_memory_regions (); where lines 202/204 are: 0x0000000010000ff4 : li r3,0 0x0000000010000ff8 : li r4,1 0x0000000010000ffc : bl 0x10013fbc = 0x0000000010001000 : nop 0x0000000010001004 : nop 0x0000000010001008 : addis r4,r2,1 0x000000001000100c : addi r3,r2,-11840 0x0000000010001010 : addi r4,r4,-5320 0x0000000010001014 : ld r3,0(r3) 0x0000000010001018 : bl 0x1002d90c = <.text+186188> 0x000000001000101c : nop And that last bl starts out at: 0x1002d90c <.text+186188>: mflr r0 0x1002d910 <.text+186192>: mfcr r12 0x1002d914 <.text+186196>: std r31,-8(r1) 0x1002d918 <.text+186200>: std r0,16(r1) 0x1002d91c <.text+186204>: stw r12,8(r1) 0x1002d920 <.text+186208>: stdu r1,-384(r1) 0x1002d924 <.text+186212>: mr r31,r1 0x1002d928 <.text+186216>: nop 0x1002d92c <.text+186220>: std r30,368(r31) 0x1002d930 <.text+186224>: addi r30,r2,11904 0x1002d934 <.text+186228>: std r28,352(r31) 0x1002d938 <.text+186232>: std r14,240(r31) 0x1002d93c <.text+186236>: std r15,248(r31) 0x1002d940 <.text+186240>: std r16,256(r31) 0x1002d944 <.text+186244>: std r17,264(r31) 0x1002d948 <.text+186248>: std r18,272(r31) 0x1002d94c <.text+186252>: std r19,280(r31) 0x1002d950 <.text+186256>: std r20,288(r31) 0x1002d954 <.text+186260>: std r21,296(r31) 0x1002d958 <.text+186264>: std r22,304(r31) 0x1002d95c <.text+186268>: std r23,312(r31) 0x1002d960 <.text+186272>: std r24,320(r31) 0x1002d964 <.text+186276>: std r25,328(r31) 0x1002d968 <.text+186280>: std r26,336(r31) 0x1002d96c <.text+186284>: std r27,344(r31) 0x1002d970 <.text+186288>: std r29,360(r31) 0x1002d974 <.text+186292>: mr r28,r4 0x1002d978 <.text+186296>: ld r3,0(r30) . . . (r3 is replaced before its value is used.) Around 0x000000001002dc78 (for #0) is: 0x1002dc0c <.text+186956>: b 0x1002de6c <.text+187564> 0x1002dc10 <.text+186960>: cmplwi r4,0 0x1002dc14 <.text+186964>: beq- 0x1002e0a0 <.text+188128> 0x1002dc18 <.text+186968>: li r3,20 0x1002dc1c <.text+186972>: li r22,4 0x1002dc20 <.text+186976>: li r30,0 0x1002dc24 <.text+186980>: li r6,0 0x1002dc28 <.text+186984>: b 0x1002dc64 <.text+187044> 0x1002dc2c <.text+186988>: li r6,1 0x1002dc30 <.text+186992>: cmplwi r4,0 0x1002dc34 <.text+186996>: li r30,80 0x1002dc38 <.text+187000>: beq- 0x1002dc40 <.text+187008> 0x1002dc3c <.text+187004>: li r30,0 0x1002dc40 <.text+187008>: li r3,17 0x1002dc44 <.text+187012>: li r22,1 0x1002dc48 <.text+187016>: b 0x1002dc64 <.text+187044> 0x1002dc4c <.text+187020>: li r6,1 0x1002dc50 <.text+187024>: cmplwi r5,0 0x1002dc54 <.text+187028>: beq- 0x1002e0a0 <.text+188128> 0x1002dc58 <.text+187032>: li r3,18 0x1002dc5c <.text+187036>: li r22,2 0x1002dc60 <.text+187040>: li r30,0 0x1002dc64 <.text+187044>: cmpwi r6,0 0x1002dc68 <.text+187048>: crnot 4*cr5+lt,eq 0x1002dc6c <.text+187052>: beq- cr2,0x1002dd14 <.text+187220> 0x1002dc70 <.text+187056>: bge- cr5,0x1002dcf4 <.text+187188> 0x1002dc74 <.text+187060>: ld r4,544(r15) 0x1002dc78 <.text+187064>: ld r4,80(r4) 0x1002dc7c <.text+187068>: cmpldi r4,0 0x1002dc80 <.text+187072>: bne- 0x1002dc94 <.text+187092> 0x1002dc84 <.text+187076>: b 0x1002dcac <.text+187116> info reg show r4 as 0x0. I expect that the failure is during the tls_get_addr dereference in htab->tls_get_addr->elf.plt.plist in the first loop below: htab->tls_get_addr is NULL as far as I can tell. . . In ppc_before_allocation : if (expecting_tls_get_addr) { struct plt_entry *ent; for (ent =3D htab->tls_get_addr->elf.plt.plist; ent !=3D NULL; ent =3D ent->next) if (ent->addend =3D=3D 0) { if (ent->plt.refcount > 0) { ent->plt.refcount -=3D 1; expecting_tls_get_addr =3D 0; } break; } } if (expecting_tls_get_addr) { struct plt_entry *ent; for (ent =3D htab->tls_get_addr_fd->elf.plt.plist; ent !=3D NULL; ent =3D ent->next) if (ent->addend =3D=3D 0) { if (ent->plt.refcount > 0) ent->plt.refcount -=3D 1; break; } } =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Jul 3 13:28: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 3C4B39E6CC2; Mon, 3 Jul 2017 13:28:14 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) (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 07FC67022D; Mon, 3 Jul 2017 13:28:13 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (localhost [127.0.0.1]) by ainaz.pair.com (Postfix) with ESMTP id 34E5B3F599; Mon, 3 Jul 2017 09:28:06 -0400 (EDT) Received: from [192.168.1.114] (unknown [202.188.138.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ainaz.pair.com (Postfix) with ESMTPSA id 23ECF3F590; Mon, 3 Jul 2017 09:27:53 -0400 (EDT) Date: Mon, 03 Jul 2017 21:27:31 +0800 User-Agent: K-9 Mail for Android In-Reply-To: <1BFFF3BD-7658-452F-9369-7C2AED479FB6@dsl-only.net> References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> <8F50FB7C-498C-453E-AE5A-EADC60758730@dsl-only.net> <1BFFF3BD-7658-452F-9369-7C2AED479FB6@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: It looks like USE_GCC=any is broken and leads to system-clang use To: Mark Millard CC: FreeBSD Toolchain , FreeBSD Ports From: Gerald Pfeifer Message-ID: 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, 03 Jul 2017 13:28:14 -0000 Am 3=2E Juli 2017 13:30:13 GMT+08:00 schrieb Mark Millard : >[More on the behavior: it is more complicated than >previously shown=2E] It's actually pretty simple (I think)=2E Mk/bsd=2Egcc=2Emk only uses lang/= gcc* ports that represent releases, not lang/gcc*-devel that represent snap= shots=2E So your patch is out of spec=2E (I have had lang/gcc7 essentially ready for weeks, alas on a system that i= s a dead brick due to loss of its power brick and me traveling=2E Should be= finally addressed by the end of this week=2E) Gerald From owner-freebsd-toolchain@freebsd.org Tue Jul 4 14:23:56 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 9E484D92F21 for ; Tue, 4 Jul 2017 14:23:56 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 19D9B7C99B for ; Tue, 4 Jul 2017 14:23:56 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x236.google.com with SMTP id r36so72359753ioi.1 for ; Tue, 04 Jul 2017 07:23:56 -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; bh=A2tFDkHVz9hqTV9157GAO7iGSxtlseDzG3NCzcPVbzc=; b=LcZVpNm/qV+FdQP6D3S0ahhIEvRonNf8Ah6M51XIJ2UFCH0ho2IabdEoLW1sjRAUjD wuNB3eMEQEeekbKhUYeiUDs0zCZl4LhPrYoMHO5xsVLbNWsUMYDc/00Nu6eh3QSDO545 dciJ86+N5RQdAHWB3iFWdMFP6DjcfgSm0KUZxFAsOJZMQ7+cDDkDbP6oN6HB2lXQU0Do pDsmpBnYly0SO+Z9RsRPVXOy6dIoa5BgISQhVi/wEhxn2xSjmuQFPNg81r7MtdbKyFU+ 98BtKu072BKUBAImjuvQM3dQWLAAnTeOz0F0xVSVlRSRzOJ6FifpHo0UBG/Ve25d5NvJ KBtA== 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; bh=A2tFDkHVz9hqTV9157GAO7iGSxtlseDzG3NCzcPVbzc=; b=coQvzjDddgmv5FODuZxr0A1vtgpPoy71lyTegHb68pJSN0HpxBChyC31keBU8sx+bW XRPDu4MN6C+zlGJU/z67B1+G+jWigRtj4TjO08fcngv2AJem2YsgHfigLAJftlfg7hn+ 0pCkLE/We4Yem5MAv0lBlU825PPtus9Sq3dKRk+JCmMCb7so/SXdGPsUsy94EVr+czl9 R9cJEZa1FBHdt4VaF/mHJmdUu6cuxyfSXW96bFJVndY89G0N0ZOwty+P34LVa9CjDbW3 llyfuhM1DPSMeXPcH6XVH6t/SI4Elbn1GK6dM0fjnnOEBOEsKNBJfQyrGcVc2PZoMp9R JzfA== X-Gm-Message-State: AIVw112J6CFq8TQKI+L4LrAVI3NVv+yEZUI622Zl/v4xaxlPxgYa5mve iuYcTB202RaRHD7/XrvBKmmPsGu7pLcc X-Received: by 10.107.178.65 with SMTP id b62mr9768918iof.113.1499178234979; Tue, 04 Jul 2017 07:23:54 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.10.85 with HTTP; Tue, 4 Jul 2017 07:23:34 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Tue, 4 Jul 2017 10:23:34 -0400 X-Google-Sender-Auth: zO4nTFkrPmq5NxZxkyOx0ZToJIc Message-ID: Subject: Re: June 2017 update on using LLVM's lld linker in the FreeBSD base system To: "freebsd-toolchain@freebsd.org" Content-Type: text/plain; charset="UTF-8" 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: Tue, 04 Jul 2017 14:23:56 -0000 On 12 June 2017 at 17:21, Ed Maste wrote: > Another update on using LLD as the FreeBSD base system linker: Since "amd64" and "arm64" look similar, let me clarify one point: arm64 -- 64-bit ARM -- is built with, and has as /usr/bin/ld, LLD 4.0.0. This is true in HEAD and in stable/11 (and hence the upcoming 11.1) amd64 -- 64-bit x86 -- is built with, and has as /usr/bin/ld, GNU BFD ld 2.17.50. LLD is installed as ld.lld; adding -fuse-ld=lld to CFLAGS can be used to test linking various software with LLD. Also, the amd64 linker will not change in stable/11. > Then the ports infrastructure > can automatically use ld.bfd, until the issue is addressed in the > individual port or in LLD. It will be something like > "USES=linker:not_lld" or "LLD_UNSAFE=yes" or so. Still waiting on this; once it is ready I expect to switch amd64 to LLD. > Outstanding issues with i386 and 32-bit arm prevent us from turning it > on for those architectures right now. The LLVM tracking bug in > http://llvm.org/pr23214 depends on those individual issues; i386 > should be relatively straightforward, while arm needs more work. i386 still needs investigation, but progress has been made on 32-bit arm. andrew@ booted an lld-linked arm kernel/userland to the login prompt, with a few workarounds. Note that this is specifically for armv7. LLD does not currently support earlier ARM architectures. TARGET_ARCH=armv7 support is in discussion/planning, and for now I assume that we'd initially switch only it to LLD. TARGET_ARCH=arm and TARGET_ARCH=armv6 will continue to use ld.bfd. It appears we are on a credible path to enable LLD by default in 12.0 for the tier-1 and almost tier-1 architectures of i386, amd64, armv7, arm64. From owner-freebsd-toolchain@freebsd.org Tue Jul 4 19:34: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 147F2D991F1 for ; Tue, 4 Jul 2017 19:34:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 D0243133B for ; Tue, 4 Jul 2017 19:34:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32312 invoked from network); 4 Jul 2017 19:32:23 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 4 Jul 2017 19:32:23 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Tue, 04 Jul 2017 15:28:04 -0400 (EDT) Received: (qmail 19583 invoked from network); 4 Jul 2017 19:28:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Jul 2017 19:28:04 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id F3EF1EC85D5; Tue, 4 Jul 2017 12:28:03 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: system clang on powerpc64 vs building lang/gcc7-devel with it: xgcc gets segmentation fault Message-Id: <493B86B0-608C-4DCF-83F4-398385F8F01D@dsl-only.net> Date: Tue, 4 Jul 2017 12:28:03 -0700 To: FreeBSD PowerPC ML , FreeBSD Toolchain 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: Tue, 04 Jul 2017 19:34:46 -0000 I have submitted: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D81315 for the below, presuming for now that the problem is on the GCC side of things. Hopefully it is not tied to include-fixed/ now being empty. [We will see if the GCC folks object to the include-fixed/ having empty or not.] I was trying to build lang/gcc7-devel on FreeBSD head -r320570 on a powerpc64. The xgcc stage got the following segmentation fault. (By contrast 32-bit powerpc's build completed without having this problem.) And the crash was repeatable: the below is from a -save-temps rerun. xgcc: warning: -pipe ignored because -save-temps specified Reading specs from = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/specs = COLLECT_GCC=3D/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./g= cc/xgcc Target: powerpc64-portbld-freebsd12.0 Configured with: = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/configure= --enable-multilib --with-build-config=3Dbootstrap-debug --disable-nls = --enable-gnu-indirect-function --libdir=3D/usr/local/lib/gcc7 = --libexecdir=3D/usr/local/libexec/gcc7 --program-suffix=3D7 = --with-as=3D/usr/local/bin/as --with-gmp=3D/usr/local = --with-gxx-include-dir=3D/usr/local/lib/gcc7/include/c++/ = --with-ld=3D/usr/local/bin/ld --with-pkgversion=3D'FreeBSD Ports = Collection' --with-system-zlib --enable-languages=3Dc,c++,objc,fortran = --prefix=3D/usr/local --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/gcc7 --build=3Dpowerpc64-portbld-freebsd12.0 Thread model: posix gcc version 7.1.1 20170629 (FreeBSD Ports Collection)=20 COLLECT_GCC_OPTIONS=3D'-v' '-save-temps' '-shared-libgcc' '-B' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc' = '-nostdinc++' = '-L/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-port= bld-freebsd12.0/libstdc++-v3/src' = '-L/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-port= bld-freebsd12.0/libstdc++-v3/src/.libs' = '-L/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-port= bld-freebsd12.0/libstdc++-v3/libsupc++/.libs' '-B' = '/usr/local/powerpc64-portbld-freebsd12.0/bin/' '-B' = '/usr/local/powerpc64-portbld-freebsd12.0/lib/' '-isystem' = '/usr/local/powerpc64-portbld-freebsd12.0/include' '-isystem' = '/usr/local/powerpc64-portbld-freebsd12.0/sys-include' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc+= +-v3/../libgcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbl= d-freebsd12.0/libstdc++-v3/include/powerpc64-portbld-freebsd12.0' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbl= d-freebsd12.0/libstdc++-v3/include' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc+= +-v3/libsupc++' '-D' '_GLIBCXX_SHARED' '-fno-implicit-templates' '-Wall' = '-Wextra' '-Wwrite-strings' '-Wcast-qual' '-Wabi' = '-fdiagnostics-show-location=3Donce' '-ffunction-sections' = '-fdata-sections' '-frandom-seed=3Dclass_type_info.lo' '-O2' '-pipe' = '-B' '/usr/local/bin/' '-D' 'LIBICONV_PLUG' '-g' '-fno-strict-aliasing' = '-B' '/usr/local/bin/' '-D' 'LIBICONV_PLUG' '-c' '-fPIC' '-D' 'PIC' '-D' = '_GLIBCXX_SHARED' '-o' 'class_type_info.o' /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/cc1plus = -E -quiet -nostdinc++ -v -I = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++= -v3/../libgcc -I = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbld= -freebsd12.0/libstdc++-v3/include/powerpc64-portbld-freebsd12.0 -I = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbld= -freebsd12.0/libstdc++-v3/include -I = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++= -v3/libsupc++ -iprefix = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/gcc/../lib/gcc7/g= cc/powerpc64-portbld-freebsd12.0/7.1.1/ -isystem = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/include = -isystem = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/include-fix= ed -D _GLIBCXX_SHARED -D LIBICONV_PLUG -D LIBICONV_PLUG -D PIC -D = _GLIBCXX_SHARED -isystem = /usr/local/powerpc64-portbld-freebsd12.0/include -isystem = /usr/local/powerpc64-portbld-freebsd12.0/sys-include = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++= -v3/libsupc++/class_type_info.cc -Wall -Wextra -Wwrite-strings = -Wcast-qual -Wabi -fno-implicit-templates = -fdiagnostics-show-location=3Donce -ffunction-sections -fdata-sections = -frandom-seed=3Dclass_type_info.lo -fno-strict-aliasing -fPIC -g = -fworking-directory -O2 -fpch-preprocess -o class_type_info.ii ignoring nonexistent directory = "/usr/local/powerpc64-portbld-freebsd12.0/include" ignoring nonexistent directory = "/usr/local/powerpc64-portbld-freebsd12.0/sys-include" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/gcc/../lib/gcc7/= gcc/powerpc64-portbld-freebsd12.0/7.1.1/include" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/gcc/../lib/gcc7/= gcc/powerpc64-portbld-freebsd12.0/7.1.1/include-fixed" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/gcc/../lib/gcc7/= gcc/powerpc64-portbld-freebsd12.0/7.1.1/../../../../../powerpc64-portbld-f= reebsd12.0/include" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/gcc/../lib/gcc7/= gcc/../../../lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.1.1/include" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/gcc/../lib/gcc7/= gcc/../../../lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.1.1/include-fixe= d" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/gcc/../lib/gcc7/= gcc/../../../lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.1.1/../../../../= ../powerpc64-portbld-freebsd12.0/include" #include "..." search starts here: #include <...> search starts here: = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++= -v3/../libgcc = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbld= -freebsd12.0/libstdc++-v3/include/powerpc64-portbld-freebsd12.0 = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbld= -freebsd12.0/libstdc++-v3/include = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++= -v3/libsupc++ /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/include = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/include-fix= ed /usr/local/include /usr/include End of search list. COLLECT_GCC_OPTIONS=3D'-v' '-save-temps' '-shared-libgcc' '-B' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc' = '-nostdinc++' = '-L/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-port= bld-freebsd12.0/libstdc++-v3/src' = '-L/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-port= bld-freebsd12.0/libstdc++-v3/src/.libs' = '-L/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-port= bld-freebsd12.0/libstdc++-v3/libsupc++/.libs' '-B' = '/usr/local/powerpc64-portbld-freebsd12.0/bin/' '-B' = '/usr/local/powerpc64-portbld-freebsd12.0/lib/' '-isystem' = '/usr/local/powerpc64-portbld-freebsd12.0/include' '-isystem' = '/usr/local/powerpc64-portbld-freebsd12.0/sys-include' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc+= +-v3/../libgcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbl= d-freebsd12.0/libstdc++-v3/include/powerpc64-portbld-freebsd12.0' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbl= d-freebsd12.0/libstdc++-v3/include' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc+= +-v3/libsupc++' '-D' '_GLIBCXX_SHARED' '-fno-implicit-templates' '-Wall' = '-Wextra' '-Wwrite-strings' '-Wcast-qual' '-Wabi' = '-fdiagnostics-show-location=3Donce' '-ffunction-sections' = '-fdata-sections' '-frandom-seed=3Dclass_type_info.lo' '-O2' '-pipe' = '-B' '/usr/local/bin/' '-D' 'LIBICONV_PLUG' '-g' '-fno-strict-aliasing' = '-B' '/usr/local/bin/' '-D' 'LIBICONV_PLUG' '-c' '-fPIC' '-D' 'PIC' '-D' = '_GLIBCXX_SHARED' '-o' 'class_type_info.o' /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/cc1plus = -fpreprocessed class_type_info.ii -quiet -dumpbase class_type_info.cc = -auxbase-strip class_type_info.o -g -O2 -Wall -Wextra -Wwrite-strings = -Wcast-qual -Wabi -version -fno-implicit-templates = -fdiagnostics-show-location=3Donce -ffunction-sections -fdata-sections = -frandom-seed=3Dclass_type_info.lo -fno-strict-aliasing -fPIC -o = class_type_info.s GNU C++14 (FreeBSD Ports Collection) version 7.1.1 20170629 = (powerpc64-portbld-freebsd12.0) compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 4.0.0 = (tags/RELEASE_400/final 297347), GMP version 6.1.2, MPFR version = 3.1.5-p2, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=3D30 --param = ggc-min-heapsize=3D4096 GNU C++14 (FreeBSD Ports Collection) version 7.1.1 20170629 = (powerpc64-portbld-freebsd12.0) compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 4.0.0 = (tags/RELEASE_400/final 297347), GMP version 6.1.2, MPFR version = 3.1.5-p2, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=3D30 --param = ggc-min-heapsize=3D4096 Compiler executable checksum: 9b3c45692665b5f6f0fb0529d1f75edd = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++= -v3/libsupc++/class_type_info.cc: In member function 'virtual bool = __cxxabiv1::__class_type_info::__do_upcast(const = __cxxabiv1::__class_type_info*, void**) const': = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++= -v3/libsupc++/class_type_info.cc:45:6: internal compiler error: = Segmentation fault bool __class_type_info:: ^~~~~~~~~~~~~~~~~ no stack trace because unwind library not available Please submit a full bug report, with preprocessed source if appropriate. See for instructions. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Wed Jul 5 19:36:13 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 5C3DAD8F773; Wed, 5 Jul 2017 19:36:13 +0000 (UTC) (envelope-from bdrewery@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 2812D6A1CC; Wed, 5 Jul 2017 19:36:13 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 2FDBE1183A; Wed, 5 Jul 2017 19:36:12 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 68A24589B; Wed, 5 Jul 2017 19:36:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 1BFMCoBk0twv; Wed, 5 Jul 2017 19:36:06 +0000 (UTC) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing) DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 92D805896 To: Mark Millard , Ed Maste Cc: FreeBSD Toolchain , FreeBSD PowerPC ML References: <0E42D991-D350-4DC1-A683-CEA506167520@dsl-only.net> From: Bryan Drewery Organization: FreeBSD Message-ID: Date: Wed, 5 Jul 2017 12:36:04 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tRAFk1842448Qbna1EXMCDiGJhW1W5n2x" 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, 05 Jul 2017 19:36:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tRAFk1842448Qbna1EXMCDiGJhW1W5n2x Content-Type: multipart/mixed; boundary="IE5eqqjihpXp6xEoUSdoF6G8Rf4c1iWLi"; protected-headers="v1" From: Bryan Drewery To: Mark Millard , Ed Maste Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Message-ID: Subject: Re: head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing) References: <0E42D991-D350-4DC1-A683-CEA506167520@dsl-only.net> In-Reply-To: --IE5eqqjihpXp6xEoUSdoF6G8Rf4c1iWLi Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/29/17 6:21 PM, Mark Millard wrote: > [I found where the tools are listed that are copied, > the list that is missing head.] >=20 > On 2017-Jun-29, at 3:33 PM, Mark Millard wrote: >=20 >> [This is a clang targetting powerpc64 context from my >> experimentation efforts, not the normal gcc 4.2.1 context >> for powerpc64.] >> >> I break out the PATH into lines below to make it easier to scan. >> See the later "sh: head: not found" line and the even later ls >> of the directory with the x86-64 program directory in use: no >> "head" is present to find. >> >> --- install32 --- >> cd /usr/src/lib; MACHINE=3Dpowerpc MACHINE_ARCH=3Dpowerpc MAKEOBJDIRPR= EFIX=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src= /world32 >> PATH=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/tmp/legacy/usr/sbin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/legacy/usr/bin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/legacy/bin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/usr/sbin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/usr/bin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/legacy/usr/sbin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/legacy/usr/bin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/legacy/bin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/usr/sbin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/usr/bin >> :/tmp/install.7ljKosWa >> SYSROOT=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/u= sr/src/lib32 LIBDIR=3D/usr/lib32 SHLIBDIR=3D/usr/lib32 DTRACE=3D"dtrace" = make LD=3D"/usr/local/powerpc64-freebsd/bin/ld -m elf32ppc_fbsd" OBJCOPY=3D= "/usr/local/powerpc64-freebsd/bin/objcopy" NM=3D"/usr/local/powerpc64-fre= ebsd/bin/nm" -DCOMPAT_32BIT CC=3D"cc -target powerpc64-unknown-freebsd12.= 0 --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/= usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -DCOMPAT_32BIT -mcpu=3Dpo= werpc -m32 -L/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/= usr/src/lib32/usr/lib32 --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinu= tils/powerpc.powerpc64/usr/src/lib32 -B/usr/local/powerpc64-freebsd/bin/= -B/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib= 32/usr/lib32" CXX=3D"c++ -target powerpc64-unknown-freebsd12.0 --sysroot= =3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp= -B/usr/local/powerpc64-freebsd/bin/ -DCOMPAT_32BIT -mcpu=3Dpowerpc -m32= -L/ >> usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib3= 2/usr/lib32 --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc= =2Epowerpc64/usr/src/lib32 -B/usr/local/powerpc64-freebsd/bin/ -B/usr/ob= j/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib= 32" CPP=3D"cpp -target powerpc64-unknown-freebsd12.0 --sysroot=3D/usr/obj= /powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp -B/usr/loc= al/powerpc64-freebsd/bin/ -DCOMPAT_32BIT -mcpu=3Dpowerpc -m32 -L/usr/obj= /powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib3= 2 --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64= /usr/src/lib32 -B/usr/local/powerpc64-freebsd/bin/ -B/usr/obj/powerpc64v= tsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib32" -DNO_CPU= _CFLAGS MK_CTF=3Dno -DNO_LINT MK_TESTS=3Dno MK_MAN=3Dno MK_HTML=3Dno MK_= TOOLCHAIN=3Dno -DLIBRARIES_ONLY install >> sh: head: not found >> make[4]: "/usr/src/share/mk/bsd.linker.mk" line 47: Unable to determin= e linker type from XLD=3D/usr/local/powerpc64-freebsd/bin/ld >> *** [install32] Error code 1 >> >> # ls -lT /tmp/install.7ljKosWa/ >> total 6151 >> -r-xr-xr-x 1 root wheel 12592 Jun 29 14:02:46 2017 [ >> -r-xr-xr-x 1 root wheel 207320 Jun 29 14:02:46 2017 awk >> -r-xr-xr-x 1 root wheel 8456 Jun 29 14:02:46 2017 cap_mkdb >> -r-xr-xr-x 1 root wheel 13272 Jun 29 14:02:46 2017 cat >> . . . >> -r-xr-xr-x 1 root wheel 57632 Jun 29 14:02:46 2017 find >> -r-xr-xr-x 1 root wheel 99064 Jun 29 14:02:46 2017 grep >> -r-xr-xr-x 1 root wheel 13360 Jun 29 14:02:46 2017 id >> . . . >> >> So there is no "head" to find. Below uses "find" instead >> to confirm the x86-64 ELF status: >> >> # file /tmp/install.7ljKosWa/find >> /tmp/install.7ljKosWa/find: ELF 64-bit LSB executable, x86-64, version= 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for F= reeBSD 12.0 (1200036), FreeBSD-style, stripped >> >> >> >> From /usr/src/share/mk/bsd.linker.mk : >> >> .if ${ld} =3D=3D "LD" || (${ld} =3D=3D "XLD" && ${XLD} !=3D ${LD}) >> .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION) >> _ld_version!=3D ${${ld}} --version 2>/dev/null | head -n 1 || echo n= one >> .if ${_ld_version} =3D=3D "none" >> .error Unable to determine linker type from ${ld}=3D${${ld}} >> .endif >> >> >> Trying the failing line interactively (no PATH >> like above though): >> >> # /usr/local/powerpc64-freebsd/bin/ld --version 2>/dev/null | head -n = 1 || echo none >> GNU ld (GNU Binutils) 2.28 >> >> So /tmp/install.7ljKosWa/ just needed a copy of head >> in addition to what it already had. >=20 > In /usr/src/Makefile.inc1 : >=20 > ITOOLS=3D [ awk cap_mkdb cat chflags chmod chown cmp cp \ > date echo egrep find grep id install ${_install-info} \ > ln make mkdir mtree mv pwd_mkdb \ > rm sed services_mkdb sh strip sysctl test true uname wc ${_zone= info} \ > ${LOCAL_ITOOLS} >=20 > does not list "head" as a tool. >=20 > But I can externally add it via LOCAL_ITOOLS use. >=20 This change should not be needed. We don't want to be running 'ld' during installworld. The changes I made around this time should already cover the problem. Is it still occurring on a more recent buildworld+installworld, without the ITOOLS change? >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 --=20 Regards, Bryan Drewery --IE5eqqjihpXp6xEoUSdoF6G8Rf4c1iWLi-- --tRAFk1842448Qbna1EXMCDiGJhW1W5n2x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZXT+kAAoJEDXXcbtuRpfP308H/1hmVq9c1gMbTuV9nGjqzvtE 6/OdahqnpwUe+KPUriWxy5jk48s3Cl94UhE9r3tG/vxjTxSTb6QgIBsGF+6ei2yy mrSiXYZxkaVIW3VAKV8BmuMHX9zlMdoVMZtGDp+Hj0lc51LekSXvsgONrcQ1IVao MYmhjlv4FZebGuOKdGKx36Hzx1Tz1sbXv+ZbdRN3b4Mx28Pv2v2d1qPv/bzT6K6D V+TyrimxwP/y0ZNLEyGLLEJXnlrIrEWJ918wgytInRIyNdMEXnDawyK8psw4sMkI OD1PPe1i3S80hR8nVUkuTv5Eeb/EVKaxPX5AnIAkyM5cs4S2QnvZCthrulGSVko= =htt7 -----END PGP SIGNATURE----- --tRAFk1842448Qbna1EXMCDiGJhW1W5n2x-- From owner-freebsd-toolchain@freebsd.org Wed Jul 5 20:42: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 76AF1D9168A for ; Wed, 5 Jul 2017 20:42:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net [208.70.210.4]) (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 36E4D700C2 for ; Wed, 5 Jul 2017 20:42:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4180 invoked from network); 5 Jul 2017 20:35:42 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 5 Jul 2017 20:35:42 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Wed, 05 Jul 2017 16:35:42 -0400 (EDT) Received: (qmail 1960 invoked from network); 5 Jul 2017 20:35:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Jul 2017 20:35:42 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 66E85EC7B2C; Wed, 5 Jul 2017 13:35:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing) From: Mark Millard In-Reply-To: Date: Wed, 5 Jul 2017 13:35:40 -0700 Cc: Ed Maste , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <8E16AF37-4D8B-4099-B366-2BA95632ECA7@dsl-only.net> References: <0E42D991-D350-4DC1-A683-CEA506167520@dsl-only.net> To: Bryan Drewery 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, 05 Jul 2017 20:42:24 -0000 On 2017-Jul-5, at 12:36 PM, Bryan Drewery wrote: > On 6/29/17 6:21 PM, Mark Millard wrote: >> [I found where the tools are listed that are copied, >> the list that is missing head.] >>=20 >> . . . >> In /usr/src/Makefile.inc1 : >>=20 >> ITOOLS=3D [ awk cap_mkdb cat chflags chmod chown cmp cp \ >> date echo egrep find grep id install ${_install-info} \ >> ln make mkdir mtree mv pwd_mkdb \ >> rm sed services_mkdb sh strip sysctl test true uname wc = ${_zoneinfo} \ >> ${LOCAL_ITOOLS} >>=20 >> does not list "head" as a tool. >>=20 >> But I can externally add it via LOCAL_ITOOLS use. >>=20 >=20 > This change should not be needed. We don't want to be running 'ld' > during installworld. The changes I made around this time should = already > cover the problem. Is it still occurring on a more recent > buildworld+installworld, without the ITOOLS change? ld was still in use last I checked. I've been using LOCAL_ITOOLS to avoid the problem for powerpc64's world32 activity where the problem was happening for me. See Ed Maste's -r320502 check in which I expect is a alternate workaround for the lack of "head" in that I get the same message that is being avoided unless I cause "head" to be in the ITOOLS: Author: emaste Date: Fri Jun 30 16:34:17 2017 New Revision: 320502 URL:=20 https://svnweb.freebsd.org/changeset/base/320502 Log: bsd.linker.mk: add band-aid for linker invocation failure =20 In some cases bsd.linker.mk reports an error like: =20 make[4]: ".../share/mk/bsd.linker.mk" line 56: Unknown linker from LD=3Dld -m elf32ppc_fbsd:" =20 For now change this to a .warning, and then assume GNU ld 2.17.50. At present the linker type detection is used only for enabling = build-id, and we can carry on without it when type detection fails. =20 Also, show errors from ${LD} --version to aid in failure diagnosis. Successful invocations of ${LD} --version produce no output on stderr so this will not create any spam in non-failing builds. =20 Tested by: swills Sponsored by: The FreeBSD Foundation Differential Revision:=09 https://reviews.freebsd.org/D11424 Modified: head/share/mk/bsd.linker.mk Modified: head/share/mk/bsd.linker.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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/share/mk/bsd.linker.mk Fri Jun 30 16:16:21 2017 = (r320501) +++ head/share/mk/bsd.linker.mk Fri Jun 30 16:34:17 2017 = (r320502) @@ -47,9 +47,9 @@ ${var}=3D ${${var}.${${X_}_ld_hash}} =20 .if ${ld} =3D=3D "LD" || (${ld} =3D=3D "XLD" && ${XLD} !=3D ${LD}) .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION) -_ld_version!=3D ${${ld}} --version 2>/dev/null | head -n 1 || = echo none +_ld_version!=3D (${${ld}} --version || echo none) | head -n 1 .if ${_ld_version} =3D=3D "none" -.error Unable to determine linker type from ${ld}=3D${${ld}} +.warning Unable to determine linker type from ${ld}=3D${${ld}} .endif .if ${_ld_version:[1..2]} =3D=3D "GNU ld" ${X_}LINKER_TYPE=3D bfd @@ -58,7 +58,9 @@ _v=3D ${_ld_version:M[1-9].[0-9]*:[1]} ${X_}LINKER_TYPE=3D lld _v=3D ${_ld_version:[2]} .else -.error Unknown linker from ${ld}=3D${${ld}}: ${_ld_version} +.warning Unknown linker from ${ld}=3D${${ld}}: ${_ld_version}, = defaulting to bfd +${X_}LINKER_TYPE=3D bfd +_v=3D 2.17.50 .endif ${X_}LINKER_VERSION!=3D echo "${_v:M[1-9].[0-9]*}" | \ awk -F. '{print $$1 * 10000 + $$2 * 100 + = $$3;}' The actual error is from the piping through head when head is missing, at least in my context. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Wed Jul 5 20:54: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 97E16D919D4; Wed, 5 Jul 2017 20:54:28 +0000 (UTC) (envelope-from bdrewery@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 57BB7705D4; Wed, 5 Jul 2017 20:54:28 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 689B3130A7; Wed, 5 Jul 2017 20:54:27 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 665205A39; Wed, 5 Jul 2017 20:54:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id fqeIemkLryHy; Wed, 5 Jul 2017 20:54:23 +0000 (UTC) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing) DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com CE2735A34 To: Mark Millard Cc: Ed Maste , FreeBSD Toolchain , FreeBSD PowerPC ML References: <0E42D991-D350-4DC1-A683-CEA506167520@dsl-only.net> <8E16AF37-4D8B-4099-B366-2BA95632ECA7@dsl-only.net> From: Bryan Drewery Organization: FreeBSD Message-ID: <3bda313e-aac0-4558-6346-2d95170d2dbc@FreeBSD.org> Date: Wed, 5 Jul 2017 13:54:17 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8E16AF37-4D8B-4099-B366-2BA95632ECA7@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qWI30b2J9VMEGvwhh9RtDMRmndnIiWcrI" 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, 05 Jul 2017 20:54:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qWI30b2J9VMEGvwhh9RtDMRmndnIiWcrI Content-Type: multipart/mixed; boundary="jelPJTx6o6sONBobjlwg2LkD9EI7QdxGO"; protected-headers="v1" From: Bryan Drewery To: Mark Millard Cc: Ed Maste , FreeBSD Toolchain , FreeBSD PowerPC ML Message-ID: <3bda313e-aac0-4558-6346-2d95170d2dbc@FreeBSD.org> Subject: Re: head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing) References: <0E42D991-D350-4DC1-A683-CEA506167520@dsl-only.net> <8E16AF37-4D8B-4099-B366-2BA95632ECA7@dsl-only.net> In-Reply-To: <8E16AF37-4D8B-4099-B366-2BA95632ECA7@dsl-only.net> --jelPJTx6o6sONBobjlwg2LkD9EI7QdxGO Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/5/17 1:35 PM, Mark Millard wrote: > On 2017-Jul-5, at 12:36 PM, Bryan Drewery wrote:= >=20 >> On 6/29/17 6:21 PM, Mark Millard wrote: >>> [I found where the tools are listed that are copied, >>> the list that is missing head.] >>> >>> . . . >>> In /usr/src/Makefile.inc1 : >>> >>> ITOOLS=3D [ awk cap_mkdb cat chflags chmod chown cmp cp \ >>> date echo egrep find grep id install ${_install-info} \ >>> ln make mkdir mtree mv pwd_mkdb \ >>> rm sed services_mkdb sh strip sysctl test true uname wc ${_zon= einfo} \ >>> ${LOCAL_ITOOLS} >>> >>> does not list "head" as a tool. >>> >>> But I can externally add it via LOCAL_ITOOLS use. >>> >> >> This change should not be needed. We don't want to be running 'ld' >> during installworld. The changes I made around this time should alrea= dy >> cover the problem. Is it still occurring on a more recent >> buildworld+installworld, without the ITOOLS change? >=20 > ld was still in use last I checked. I've been using LOCAL_ITOOLS > to avoid the problem for powerpc64's world32 activity where the > problem was happening for me. >=20 > See Ed Maste's -r320502 check in which I expect is a alternate > workaround for the lack of "head" in that I get the same message > that is being avoided unless I cause "head" to be in the ITOOLS: >=20 >=20 > Author: emaste > Date: Fri Jun 30 16:34:17 2017 > New Revision: 320502 > URL:=20 > https://svnweb.freebsd.org/changeset/base/320502 >=20 >=20 > Log: > bsd.linker.mk: add band-aid for linker invocation failure > =20 > In some cases bsd.linker.mk reports an error like: > =20 > make[4]: ".../share/mk/bsd.linker.mk" line 56: > Unknown linker from LD=3Dld -m elf32ppc_fbsd:" > =20 > For now change this to a .warning, and then assume GNU ld 2.17.50. > At present the linker type detection is used only for enabling build-= id, > and we can carry on without it when type detection fails. > =20 > Also, show errors from ${LD} --version to aid in failure diagnosis. > Successful invocations of ${LD} --version produce no output on stderr= > so this will not create any spam in non-failing builds. > =20 > Tested by: swills > Sponsored by: The FreeBSD Foundation > Differential Revision:=09 > https://reviews.freebsd.org/D11424 >=20 >=20 > Modified: > head/share/mk/bsd.linker.mk >=20 > Modified: head/share/mk/bsd.linker.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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- head/share/mk/bsd.linker.mk Fri Jun 30 16:16:21 2017 (r320501) > +++ head/share/mk/bsd.linker.mk Fri Jun 30 16:34:17 2017 (r320502) > @@ -47,9 +47,9 @@ ${var}=3D ${${var}.${${X_}_ld_hash}} > =20 > .if ${ld} =3D=3D "LD" || (${ld} =3D=3D "XLD" && ${XLD} !=3D ${LD}) > .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION) > -_ld_version!=3D ${${ld}} --version 2>/dev/null | head -n 1 || echo non= e > +_ld_version!=3D (${${ld}} --version || echo none) | head -n 1 > .if ${_ld_version} =3D=3D "none" > -.error Unable to determine linker type from ${ld}=3D${${ld}} > +.warning Unable to determine linker type from ${ld}=3D${${ld}} > .endif > .if ${_ld_version:[1..2]} =3D=3D "GNU ld" > ${X_}LINKER_TYPE=3D bfd > @@ -58,7 +58,9 @@ _v=3D ${_ld_version:M[1-9].[0-9]*:[1]} > ${X_}LINKER_TYPE=3D lld > _v=3D ${_ld_version:[2]} > .else > -.error Unknown linker from ${ld}=3D${${ld}}: ${_ld_version} > +.warning Unknown linker from ${ld}=3D${${ld}}: ${_ld_version}, default= ing to bfd > +${X_}LINKER_TYPE=3D bfd > +_v=3D 2.17.50 > .endif > ${X_}LINKER_VERSION!=3D echo "${_v:M[1-9].[0-9]*}" | \ > awk -F. '{print $$1 * 10000 + $$2 * 100 + $$3;}' >=20 >=20 >=20 > The actual error is from the piping through head > when head is missing, at least in my context. Right, neither that commit nor adding head to [LOCAL_]ITOOLS should be needed. I wasn't able to recreate any of the problems when I tried last. I will look again. --=20 Regards, Bryan Drewery --jelPJTx6o6sONBobjlwg2LkD9EI7QdxGO-- --qWI30b2J9VMEGvwhh9RtDMRmndnIiWcrI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZXVH6AAoJEDXXcbtuRpfPpOEIAL83WZ4C5xN72VhNhG7iKF9/ mzHHd3WhBd0PGfQS3a1CjttGYb+cFULO9L0ku9yrI90Top9Sq4tBtdqjIqwJNRmz LdWTH5Ks5CoFYRkOXUK1iZd+OYmtmaXC8k/ajzy/M9TRnocB/g9jW2aTeTgXw6lo h40hzvIM7FbHqMQByKX3FmKMMB1IWiqeclVQFNJ7/BF4lCEmez8acVUysfESj9k/ 556zZ9AJEV02ZpwvA6OIB57PQEOq4X+3QJwxOZzU6QhuUyEA9PbVSghKz3vpIQpO QKOZU7tSxfzui4Gp6k4eJFA25xJZxjtxxfocUUBvjsAD3QSP3hsDPf9XnjiZKuU= =3LZh -----END PGP SIGNATURE----- --qWI30b2J9VMEGvwhh9RtDMRmndnIiWcrI-- From owner-freebsd-toolchain@freebsd.org Wed Jul 5 21:41: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 2D29BD92CC5 for ; Wed, 5 Jul 2017 21:41:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net [208.70.210.4]) (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 E484772202 for ; Wed, 5 Jul 2017 21:41:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29816 invoked from network); 5 Jul 2017 21:42:58 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 Jul 2017 21:42:58 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Wed, 05 Jul 2017 17:41:26 -0400 (EDT) Received: (qmail 29770 invoked from network); 5 Jul 2017 21:41:26 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Jul 2017 21:41:26 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6CC45EC8678; Wed, 5 Jul 2017 14:41:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing) From: Mark Millard In-Reply-To: <3bda313e-aac0-4558-6346-2d95170d2dbc@FreeBSD.org> Date: Wed, 5 Jul 2017 14:41:24 -0700 Cc: Ed Maste , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E42D991-D350-4DC1-A683-CEA506167520@dsl-only.net> <8E16AF37-4D8B-4099-B366-2BA95632ECA7@dsl-only.net> <3bda313e-aac0-4558-6346-2d95170d2dbc@FreeBSD.org> To: Bryan Drewery 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, 05 Jul 2017 21:41:28 -0000 [I show the specifics for how I normally build powerpc64 with world32/lib32 involved. Ed Maste's submittal also mentions "elf32ppc_fbsd". The issue's context may be powerpc64 specific.] On 2017-Jul-5, at 1:54 PM, Bryan Drewery wrote: > On 7/5/17 1:35 PM, Mark Millard wrote: >> On 2017-Jul-5, at 12:36 PM, Bryan Drewery = wrote: >>=20 >>> On 6/29/17 6:21 PM, Mark Millard wrote: >>>> [I found where the tools are listed that are copied, >>>> the list that is missing head.] >>>>=20 >>>> . . . >>>> In /usr/src/Makefile.inc1 : >>>>=20 >>>> ITOOLS=3D [ awk cap_mkdb cat chflags chmod chown cmp cp \ >>>> date echo egrep find grep id install ${_install-info} \ >>>> ln make mkdir mtree mv pwd_mkdb \ >>>> rm sed services_mkdb sh strip sysctl test true uname wc = ${_zoneinfo} \ >>>> ${LOCAL_ITOOLS} >>>>=20 >>>> does not list "head" as a tool. >>>>=20 >>>> But I can externally add it via LOCAL_ITOOLS use. >>>>=20 >>>=20 >>> This change should not be needed. We don't want to be running 'ld' >>> during installworld. The changes I made around this time should = already >>> cover the problem. Is it still occurring on a more recent >>> buildworld+installworld, without the ITOOLS change? >>=20 >> ld was still in use last I checked. I've been using LOCAL_ITOOLS >> to avoid the problem for powerpc64's world32 activity where the >> problem was happening for me. >>=20 >> See Ed Maste's -r320502 check in which I expect is a alternate >> workaround for the lack of "head" in that I get the same message >> that is being avoided unless I cause "head" to be in the ITOOLS: >>=20 >>=20 >> Author: emaste >> Date: Fri Jun 30 16:34:17 2017 >> New Revision: 320502 >> URL:=20 >> https://svnweb.freebsd.org/changeset/base/320502 >>=20 >>=20 >> Log: >> bsd.linker.mk: add band-aid for linker invocation failure >>=20 >> In some cases bsd.linker.mk reports an error like: >>=20 >> make[4]: ".../share/mk/bsd.linker.mk" line 56: >> Unknown linker from LD=3Dld -m elf32ppc_fbsd:" >>=20 >> For now change this to a .warning, and then assume GNU ld 2.17.50. >> At present the linker type detection is used only for enabling = build-id, >> and we can carry on without it when type detection fails. >>=20 >> Also, show errors from ${LD} --version to aid in failure diagnosis. >> Successful invocations of ${LD} --version produce no output on = stderr >> so this will not create any spam in non-failing builds. >>=20 >> Tested by: swills >> Sponsored by: The FreeBSD Foundation >> Differential Revision:=09 >> https://reviews.freebsd.org/D11424 >>=20 >>=20 >> Modified: >> head/share/mk/bsd.linker.mk >>=20 >> Modified: head/share/mk/bsd.linker.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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- head/share/mk/bsd.linker.mk Fri Jun 30 16:16:21 2017 = (r320501) >> +++ head/share/mk/bsd.linker.mk Fri Jun 30 16:34:17 2017 = (r320502) >> @@ -47,9 +47,9 @@ ${var}=3D ${${var}.${${X_}_ld_hash}} >>=20 >> .if ${ld} =3D=3D "LD" || (${ld} =3D=3D "XLD" && ${XLD} !=3D ${LD}) >> .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION) >> -_ld_version!=3D ${${ld}} --version 2>/dev/null | head -n 1 || = echo none >> +_ld_version!=3D (${${ld}} --version || echo none) | head -n 1 >> .if ${_ld_version} =3D=3D "none" >> -.error Unable to determine linker type from ${ld}=3D${${ld}} >> +.warning Unable to determine linker type from ${ld}=3D${${ld}} >> .endif >> .if ${_ld_version:[1..2]} =3D=3D "GNU ld" >> ${X_}LINKER_TYPE=3D bfd >> @@ -58,7 +58,9 @@ _v=3D ${_ld_version:M[1-9].[0-9]*:[1]} >> ${X_}LINKER_TYPE=3D lld >> _v=3D ${_ld_version:[2]} >> .else >> -.error Unknown linker from ${ld}=3D${${ld}}: ${_ld_version} >> +.warning Unknown linker from ${ld}=3D${${ld}}: ${_ld_version}, = defaulting to bfd >> +${X_}LINKER_TYPE=3D bfd >> +_v=3D 2.17.50 >> .endif >> ${X_}LINKER_VERSION!=3D echo "${_v:M[1-9].[0-9]*}" | \ >> awk -F. '{print $$1 * 10000 + $$2 * 100 + = $$3;}' >>=20 >>=20 >>=20 >> The actual error is from the piping through head >> when head is missing, at least in my context. >=20 > Right, neither that commit nor adding head to [LOCAL_]ITOOLS should be > needed. I wasn't able to recreate any of the problems when I tried > last. I will look again. Note that Ed Maste's submittal mentions "elf32ppc_fbsd" and the only context I've seen the issue is for powerpc64 with world32/lib32 involved as well. In my case this is with an external binutils because the system binutils fail last I tried and the llvm one do not work either. It is also the case that for me the compiler is the system's clang in my normal use. My normal powerpc64 build context in more detail, first the script that in turn binds SRC_ENV_CONF and then the bound file: # more = ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutil= s-amd64-host.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils-= amd64-host-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc64-clang_altbinutils-boo= tstrap.amd64-host" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/powerpc64vtsc_clang_altbinutils" \ make $* # more = /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-hos= t TO_TYPE=3Dpowerpc64 TOOLS_TO_TYPE=3D${TO_TYPE} VERSION_CONTEXT=3D12.0 # KERNCONF=3DGENERIC64vtsc-NODBG TARGET=3Dpowerpc .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITHOUT_LLD_BOOTSTRAP=3D WITH_LLD=3D WITHOUT_LLD_IS_LD=3D WITH_LLDB=3D # WITH_BOOT=3D WITH_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D MALLOC_PRODUCTION=3D # # Avoid converts between pointers to integer types with different sign = [-Werror,-Wpointer-sign] # and such from blocking the build. WERROR=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # # # For TO (so-called "cross") stages . . . # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . . # CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 # # Note: The WITH_CROSS_COMPILER picks up the CROSS_BINUTILS_PREFIX # binding automatically. # XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld .export XLD .endif =3D=3D=3D Mark Millard markmi at dsl-only.net