From owner-freebsd-toolchain@freebsd.org Sun Oct 29 07:10:35 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 1A359E5BC95 for ; Sun, 29 Oct 2017 07:10:35 +0000 (UTC) (envelope-from sid@bsdmail.com) Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (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 D60336EBD9 for ; Sun, 29 Oct 2017 07:10:34 +0000 (UTC) (envelope-from sid@bsdmail.com) Received: from [108.70.50.7] by 3c-app-mailcom-lxa12.server.lan (via HTTP); Sun, 29 Oct 2017 08:10:32 +0100 MIME-Version: 1.0 Message-ID: From: Sid To: "Mark Millard" , freebsd-toolchain@freebsd.org Subject: Re: External LLVM toolchain not consistently locating c++ when compiling ports Content-Type: text/plain; charset=UTF-8 Date: Sun, 29 Oct 2017 08:10:32 +0100 Importance: normal Sensitivity: Normal In-Reply-To: References: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:CCiYY/sY8iV50a3AGb4Evzwuz54cscBIEpIxb8vez0a 4aQzosxvShtM2h30QynuTUgAFSgfUmNUdWKsxtIuwGnk6lwGZi NFET5H4Qj5udXt3BDOt/1WwxCxNZGnzUZ8WHiFmUhPl+4lCVva r9rNmT18DWHKWxs47RmNL+Cw3rOaOdhLGfHis1sWKsUEDri6kC GKNxxJs3EKmJwpcD0AjuTFbRRotSCm32Fh+RegJeXruNYOF1Nf pFORUb9rZi9a3ArUblRTCh9azoS2EQH85XZE1O2LH+Xn3ei3/Q dUqSyU= X-UI-Out-Filterresults: notjunk:1;V01:K0:c6bz7S+bUJQ=:iI9od10l4ahUS/+Sfg2AH2 tDeL66nV3Rlq7VAzjBcvcSCad2G97a+UKgZguOsBqA2by0ZYcyyUuR2QEAGLY4B4EqY+VxC9W 0iZqUzB/g7uv5YLkB0hEaV7rJPWq+1pfnRs5m9bHkmBtQ0HYV3XXjZmYnqzjGxwkQ8jXWlYFH Q4i3FPPBCzRRugFHBJUFnm4Vz+AN9/3nisxJWOwTZqiB6yzj0h5BkSiSv5IsD7ehN3Lgvglt0 VOUNpEZBPQbXiwTbTvMWhPhpDianCICMW20aWCwvpPEhJ4Z0s5/X4o64eRuvGUpn7hc0q3dR2 JPhMrg1jY2kmIjWalmP6KHmt2I99iPVr1/JBOws9OHLMiwTEL2orad4yDehxYblUh4SMijrU9 Dhs+kwuG20kbq0jTE3GtEOSPRZ2JVDKGpVcecVISwg3GCbxAvVxqR/TCD6WyDzdOFRhX1EHp2 Lk+/xgS+1NTh19gTXiY1pY1Q13aA8eDgqr6VOb/fb5xSpOa4wNYZphL9hHRCLrtBv1orUOqSJ ASYs6g/+yDZn19WMkrhwlVtGBIi4LidlyYRnkXusoTf 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:10:35 -0000 Hi, 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. 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/. 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++. > 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 > > > On 2017-Oct-28, at 9:40 PM, Sid wrote: > > > In /etc/make.conf, when I use, > > XCC= /usr/local/bin/clang40 > > XCXX= /usr/local/bin/clang++40 > > XCPP= /usr/local/bin/clang-cpp40 > > for ports that require c++ without clang in the base system, I get the error code > > make: "/usr/ports/Mk/Uses/compiler.mk" line 112:warning: "c++ -### /dev/null 2>&1" returned non-zero status > > Quoting https://wiki.freebsd.org/ExternalToolchain: > > XCC > > 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. > > END QUOTE. > > Does ports support "cross building" that would be expected to use > XCC, XCXX, XCPP, and the like? > > 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. > > > Base and the kernel builds well with this setting. Compiles that don't need c++ also work with this setting. > > Unlike for ports builds. (That is my understanding.) > > > I've compensated by adding > > CC= /usr/local/bin/clang40 > > CXX= /usr/local/bin/clang++40 > > CPP= /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). > > This is what I'd expect for "self hosted" (target=build) > types of contexts and for being in a qemu context that looks > like the target. > > 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.) > > > It seems that XCXX is supposed to replace CXX fully, considering that XCC replaces CC, and XCPP replaces CPP when compiling other ports. > > Can you provide evidence of this? Does the evidence > involve cross building where the X prefix is involved? > > > 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++" > > Does the environment not have a c++ command in a place > listed in path? Otherwise it should be found. > > > 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. > > > === > Mark Millard > markmi at dsl-only.net > >