From owner-freebsd-toolchain@freebsd.org Sun Oct 29 07:48: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 7DDCDE5C920 for ; Sun, 29 Oct 2017 07:48:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-135.reflexion.net [208.70.210.135]) (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 400966FF0D for ; Sun, 29 Oct 2017 07:48:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3710 invoked from network); 29 Oct 2017 07:48:06 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Oct 2017 07:48:06 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 29 Oct 2017 03:48:06 -0400 (EDT) Received: (qmail 30599 invoked from network); 29 Oct 2017 07:48:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Oct 2017 07:48:05 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 39359EC7C1F; Sun, 29 Oct 2017 00:48:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: External LLVM toolchain not consistently locating c++ when compiling ports From: Mark Millard X-Priority: 3 In-Reply-To: Date: Sun, 29 Oct 2017 00:48:04 -0700 Cc: freebsd-toolchain@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3E01A2C6-0728-4295-90AE-76A7CE5955EF@dsl-only.net> References: To: Sid 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: Sun, 29 Oct 2017 07:48:13 -0000 On 2017-Oct-29, at 12:10 AM, Sid wrote: > This is not on Qemu, and I'm not cross-building. This is on an amd64 = on 11.1-RELEASE-p2. Base was built without clang or gcc, and clang40 was = installed from ports. >=20 > The base and kernel compile using lang/llvm40 with XCC, XCXX, and XCPP = set. I'm a little confused, as how earlier, it seemed that ports that = didn't need c++ were building without CC, CXX, and CPP options set. If = I made a mistake here, I apologize for this. It seems CC, CXX, and CPP = are made for ports. Then the problem is with Rust locating c++ that is = in /usr/local/bin/ and not contained within FreeBSD 11.1's base, in = /usr/bin/. >=20 > Nearly all programs requiring c++, needed for my desktop (xorg, = rxvt-unicode, leafpad, sox) compiled when all 6 variables were set = (CC,CPP, etc). Only Rust, and programs depending on it failed. Now I = think the problem is, that Rust and programs depending on it look in = absolute locations for c++. I'm afraid there is a clang++40 to find but no c++ to be found anywhere in your context based on what you have described. I have llvm50 installed instead of llvm40, so, that is what I'll use as an example for amd64 (head -r324743 ). . . # pkg info llvm50 llvm50-5.0.0_1 Name : llvm50 Version : 5.0.0_1 Installed on : Sun Sep 24 00:26:47 2017 PDT Origin : devel/llvm50 Architecture : FreeBSD:12:amd64 Prefix : /usr/local Categories : devel lang Licenses : LLVM Maintainer : brooks@FreeBSD.org WWW : http://llvm.org/ Comment : LLVM and Clang Options : CLANG : on COMPILER_RT : on DOCS : on EXTRAS : on GOLD : on LIT : on LLD : on LLDB : on OPENMP : on . . . But no command c++ is under /usr/local/ , there is just a directory of that name (from lang/gcc7 in my context): # find /usr/local -name c++ -print | more /usr/local/lib/gcc7/include/c++ Clang++50 is under its own name: # which clang++50 /usr/local/bin/clang++50 So without system clang (or system gcc 4.2.1) and only with llvm40 I expect that there is no c++ command at all. The issue would not be an overly-specific path: no path would work. Rust needs to not be looking for a c++ command at all. It needs to be using ${CXX} and the like that would need to involve clang++50 . But you can make a local workaround by creating your own c++ command someplace in the paths being checked, either linking to or copying clang++40 to produce the c++ . c++ might not be the only file needing such a technique. Prior material follows, nothing new so likely skip. . . > Sent: Sunday, October 29, 2017 at 12:11 AM > From: "Mark Millard" > To: Sid > Cc: freebsd-toolchain@freebsd.org > Subject: Re: External LLVM toolchain not consistently locating c++ = when compiling ports >=20 >=20 > On 2017-Oct-28, at 9:40 PM, Sid wrote: >=20 >> In /etc/make.conf, when I use, >> XCC=3D /usr/local/bin/clang40 >> XCXX=3D /usr/local/bin/clang++40 >> XCPP=3D /usr/local/bin/clang-cpp40 >> for ports that require c++ without clang in the base system, I get = the error code=20 >> make: "/usr/ports/Mk/Uses/compiler.mk" line 112:warning: "c++ -### = /dev/null 2>&1" returned non-zero status >=20 > Quoting https://wiki.freebsd.org/ExternalToolchain: >=20 > XCC >=20 > The XCC approach works with top level build targets (buildworld, = buildkernel, etc) and overrides common make variables such as CC, CXX, = and AS during the cross building portions of the build with values = specified by the XCC, XCPP, XAS, etc variables. This method touches few = files and is relatively easy to understand, but has drawbacks including = the inability to build individual programs easily.=20 >=20 > END QUOTE. >=20 > Does ports support "cross building" that would be expected to use > XCC, XCXX, XCPP, and the like? >=20 > To my knowledge there is no cross build environment for ports > that can avoid qemu (or an equivalent): cross builds of parts > are based on qemu, which use CC, CXX, CPP and the like as far > as I know. >=20 >> Base and the kernel builds well with this setting. Compiles that = don't need c++ also work with this setting. >=20 > Unlike for ports builds. (That is my understanding.) >=20 >> I've compensated by adding >> CC=3D /usr/local/bin/clang40 >> CXX=3D /usr/local/bin/clang++40 >> CPP=3D /usr/local/bin/clang-cpp40 >> to the above. While this works for many ports requiring c++, it = doesn't work for Rust, and programs that depend on it (Firefox, = Thunderbird). >=20 > This is what I'd expect for "self hosted" (target=3Dbuild) > types of contexts and for being in a qemu context that looks > like the target. >=20 > I'm not aware of another form of cross build for > FreeBSD ports. (I'd like to be able to do powerpc64 > and powerpc without a system qemu. User qemu does > not work for targeting powerpc64 or for powerpc.) >=20 >> It seems that XCXX is supposed to replace CXX fully, considering that = XCC replaces CC, and XCPP replaces CPP when compiling other ports. >=20 > Can you provide evidence of this? Does the evidence > involve cross building where the X prefix is involved? >=20 >> The error message for compiling rust with all of the above (XCC, = XCXX, XCPP, CC, CXX, CPP) set is >> couldn't find required command: "c++" >=20 > Does the environment not have a c++ command in a place > listed in path? Otherwise it should be found. >=20 >> This error happens whether the port option for lang/rust is set to = compile with llvm40 or the bundled version. >> This is affected by /usr/ports/Mk/Uses/compiler.mk and I think this = problem affects ports compiled with c++ in the base system as well. =3D=3D=3D Mark Millard markmi at dsl-only.net