Date: Sun, 29 Oct 2017 00:48:04 -0700 From: Mark Millard <markmi@dsl-only.net> To: Sid <sid@bsdmail.com> Cc: freebsd-toolchain@freebsd.org Subject: Re: External LLVM toolchain not consistently locating c++ when compiling ports Message-ID: <3E01A2C6-0728-4295-90AE-76A7CE5955EF@dsl-only.net> In-Reply-To: <trinity-368804ee-950f-4283-a4db-21bf7a5870c8-1509261032035@3c-app-mailcom-lxa12> References: <trinity-8d3dd393-342f-41d2-9781-0c9f7778b8d9-1509252017014@3c-app-mailcom-lxa12> <D285E708-6C34-43FC-9AD5-07215B6F04B4@dsl-only.net> <trinity-368804ee-950f-4283-a4db-21bf7a5870c8-1509261032035@3c-app-mailcom-lxa12>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Oct-29, at 12:10 AM, Sid <sid at bsdmail.com> 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" <markmi@dsl-only.net> > To: Sid <sid@bsdmail.com> > 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 <sid at bsdmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E01A2C6-0728-4295-90AE-76A7CE5955EF>