From owner-freebsd-toolchain@freebsd.org Sun Apr 3 07:02:30 2016 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 0A7E0B005FA for ; Sun, 3 Apr 2016 07:02:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (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 BF2EF12F4 for ; Sun, 3 Apr 2016 07:02:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19022 invoked from network); 3 Apr 2016 07:02:20 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 3 Apr 2016 07:02:20 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.2) with SMTP; Sun, 03 Apr 2016 03:02:13 -0400 (EDT) Received: (qmail 23008 invoked from network); 3 Apr 2016 07:02:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 3 Apr 2016 07:02:13 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 29735B1E001; Sat, 2 Apr 2016 23:06:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) From: Mark Millard In-Reply-To: Date: Sat, 2 Apr 2016 23:06:48 -0700 Cc: Dimitry Andric , FreeBSD Toolchain , FreeBSD Current , Gerald Pfeifer , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <53DAD70E-8DE4-4DBA-BF88-AD7F51B0B816@dsl-only.net> References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <5FDFDC6A-911B-4A77-BCEF-BBB711BFA0AC@FreeBSD.org> <5334F356-982F-40CA-9009-41B59AAC8665@dsl-only.net> To: Warner Losh , Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 03 Apr 2016 07:02:30 -0000 On 2016-Apr-2, at 3:59 PM, Mark Millard wrote: > [My testing for the likes of the below does not yet extend outside = powerpc64 contexts.] >=20 > For the likes of self-hosted powerpc64-xtoolchain-gcc/powerpc64-gcc = use with, say, gcc49 materials as the so-called "host" compiler tools I = have not yet found a way around using the workaround: >=20 >> # ls -l /usr/lib/libstdc++.* >> lrwxr-xr-x 1 root wheel 17 Feb 23 00:09 /usr/lib/libstdc++.a -> = /usr/lib/libc++.a >> lrwxr-xr-x 1 root wheel 18 Feb 23 00:09 /usr/lib/libstdc++.so -> = /usr/lib/libc++.so >=20 >=20 >=20 > But I appear to now have a src.conf (or a family of them) that avoids = needing workarounds in /usr/local/include and /usr/local/lib for = filename conflicts. This is based on CC/CXX ("HOST") and XCC/XCXX = ("CROSS") in src.conf being the likes of: >=20 > "HOST" (CC/CXX): >> CC=3Denv C_INCLUDE_PATH=3D/usr/include /usr/local/bin/gcc49 = -L/usr/lib >> CXX=3Denv C_INCLUDE_PATH=3D/usr/include = CPLUS_INCLUDE_PATH=3D/usr/include/c++/v1 /usr/local/bin/g++49 -std=3Dc++11= -nostdinc++ -L/usr/lib >=20 > and. . . >=20 > "CROSS" (XCC/XCXX): >> TO_TYPE=3Dpowerpc64 >> TOOLS_TO_TYPE=3D${TO_TYPE} >> . . . >> VERSION_CONTEXT=3D11.0 >> . . . >> = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gc= c >> = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g= ++ >=20 > In other words: CROSS use is already handled for /usr/local/. . . just = given the compiler paths but some special src.conf adjustments beyond = compiler paths were needed for HOST. >=20 > So far it appears that gcc49 materials can be used in "CROSS" and/or = powerpc64-gcc materials can be used in "HOST" via just appropriate = compiler-path editing. (I have jumped to testing -r297514 but am still = doing various build tests. So this aspect is subject to updates.) It = appears to be possible to use just one compiler/tool family --but in the = 2 different ways-- instead of using a mix of 2 compiler/tool families. >=20 > Historically I've not gotten gcc variants to make a working lib32 for = powerpc64 and I've yet to retest this: So no claims about the lib32 = status are implied here. (The problem was code in crtbeginS that = arbitrarily used R30 in a way that the context was not set up for and so = crtbeginS code was dereferencing arbitrary addresses.) I probably knew this someplace in the back of my head but gcc49 does not = handle -fformat-extensions (quoting the script log): > --- accf_data.o --- > env /usr/local/bin/gcc49 -isystem = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib = --sysroot=3D/usr/obj/xtoolchain/powerpc.powerp > c64/usr/src/tmp -B/usr/local/powerpc64-portbld-freebsd11.0/bin/ -O2 = -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG/op= t_global.h -I. -I/usr/src/sys -fno-common -g -mlongcall = -fno-omit-frame-pointer = -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG = -MD -MF.depend.accf_data.o -MTaccf_data.o -mno-altivec -ffreestanding = -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls = -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign = -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option = -Wno-unknown-pragmas -Wno-error=3Dinline -Wno-error=3Denum-compare = -Wno-error=3Dunused-but-set-variable = -Wno-error=3Daggressive-loop-optimizations = -Wno-error=3Dmaybe-uninitialized -Wno-error=3Darray-bounds = -Wno-error=3Daddress -Wno-error=3Dcast-qual -Wno-error=3Dsequence-point = -Wno-error=3Dattributes -Wno-error=3Dstrict-overflow = -Wno-error=3Doverflow -v -finline-limit=3D15000 -fms-extensions --param = inline-unit-growth=3D100 --param large-function-growth=3D1000 = -msoft-float -mcall-aixdesc -std=3Diso9899:1999 -c = /usr/src/sys/modules/accf_data/../../netinet/accf_data.c -o accf_data.o > Using built-in specs. > COLLECT_GCC=3D/usr/local/bin/gcc49 > gcc49: error: unrecognized command line option '-fformat-extensions' > Target: powerpc64-portbld-freebsd11.0 > Configured with: ./../gcc-4.9-20160210/configure --disable-multilib = --disable-bootstrap --disable-nls --enable-gnu-indirect-function = --libdir=3D/usr/local/lib/gcc49 --libexecdir=3D/usr/local/libexec/gcc49 = --program-suffix=3D49 --with-as=3D/usr/local/bin/as = --with-gmp=3D/usr/local = --with-gxx-include-dir=3D/usr/local/lib/gcc49/include/c++/ = --with-ld=3D/usr/local/bin/ld --with-pkgversion=3D'FreeBSD Ports = Collection' --with-system-zlib --disable-libgcj = --enable-languages=3Dc,c++,objc,fortran --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/gcc49 --build=3Dpowerpc64-portbld-freebsd11.0 > Thread model: posix > gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection)=20 > *** [accf_data.o] Error code 1 So my > it appears that gcc49 materials can be used in "CROSS" is just false for gcc49, gcc5, and the like. I had hoped such would work with TARGET_ARCH=3Dpowerpc because there is = no powerpc-gcc port predefined and clang 3.8.0 is still insufficient for = this context. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Apr-1, at 4:35 PM, Mark Millard wrote: >=20 > [Just a top-post showing what powerpc64-xtoolchain-gcc/powerpc64-gcc = has for the default include search places:] >=20 > powerpc64-xtoolchain-gcc/powerpc64-gcc also looks in = /usr/local/include before /usr/include : see below. >=20 >> # portmaster --list-origins >> . . . >> devel/powerpc64-xtoolchain-gcc >> . . . >>=20 >> # /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc --version >> powerpc64-portbld-freebsd11.0-gcc (FreeBSD Ports Collection for = powerpc64) 5.3.0 >> Copyright (C) 2015 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There = is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. >>=20 >> # echo '' |/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -v -x c++ = - -o /dev/null >> . . . >> ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../includ= e/c++/5.3.0" >> ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../includ= e/c++/5.3.0/powerpc64-portbld-freebsd11.0" >> ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../includ= e/c++/5.3.0/backward" >> ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerp= c64-portbld-freebsd11.0/include" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include >> /usr/local/include >> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed >> /usr/include >> End of search list. >> . . . >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > On 2016-Apr-1, at 7:25 AM, Warner Losh wrote: >=20 >=20 >=20 > On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric = wrote: > On 01 Apr 2016, at 00:44, Warner Losh wrote: >>=20 >>> On Mar 31, 2016, at 4:34 PM, Bryan Drewery = wrote: >>> I didn't realize the ports compiler was defaulting = /usr/local/include >>> into the search path now. It does not have /usr/local/lib in the >>> default library path as far as I can tell. It's also broken for its >>> -rpath (noted in its pkg-message). So having a default >>> /usr/local/include path seems odd. >>=20 >> It has for a while now. It=E2=80=99s one of the maddening = inconsistencies that abound in this >> area. I took a poll a while ago and there seemed to be widespread = support for adding >> it to the base compiler. >=20 > This was the main reason /usr/local/include was *not* included in the > base compiler, otherwise it would unpredictably pick up headers in > /usr/local/include during builds. You can never know which = conflicting > headers a certain user has installed in /usr/local/include... :) >=20 > That's why it shouldn't be *FIRST*, not why it shouldn't be there > at all. >=20 >>> Adding -isystem /usr/include to fix this is probably possible but >>> there's a risk someone will remove it as redundant. In this case I = wish >>> /usr/include was first but I'm not sure what impact that would have = on >>> consumers expecting /usr/local/include (and /usr/local/lib) = overrides to >>> work, though they would need to pass a -L /usr/local/lib anyhow and >>> would likely be passing -I /usr/local/lib too. >>=20 >> /usr/include should be first. But it isn=E2=80=99t. That=E2=80=99s = another inconsistency that was found >> when we looked at /usr/local stuff. Someone recently added = /usr/local/bin to the path, >> if I recall correctly. >=20 > Isn't that a bit of a bikeshed? I guess some people would just as = well > prefer /usr/local/include to be first, just like some people prefer > /usr/local/bin before /usr/bin in their PATH. >=20 > Sigh. No. /usr/local is moving into many different things in the base = and ports. We should > do it in a consistent way. What we have now is not consistent and = somewhat brittle. >=20 > In any case, if such paths are added to external compilers, we better > make sure almost everything in buildworld uses -nostdinc, and = specifying > exactly the include directories we need, and no others. Cumbersome, = but > maybe for a good cause. >=20 > That's the non-brittle solution here. An over-reliance on defaults = makes it > difficult to ensure other compilers will work, especially ones we = don't > tightly control the defaults for. >=20 > Warner From owner-freebsd-toolchain@freebsd.org Mon Apr 4 04:25:41 2016 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 2DB24AEC0DC for ; Mon, 4 Apr 2016 04:25:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (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 D84B71358 for ; Mon, 4 Apr 2016 04:25:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13046 invoked from network); 4 Apr 2016 04:26:00 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 4 Apr 2016 04:26:00 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.2) with SMTP; Mon, 04 Apr 2016 00:25:29 -0400 (EDT) Received: (qmail 5435 invoked from network); 4 Apr 2016 04:25:29 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 4 Apr 2016 04:25:29 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1B8D0B1E001; Sun, 3 Apr 2016 21:25:32 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0: head/lib/libsysdecode/Makefile for . . ./libsoft/usr/include uses CPP when XCPP needed? Message-Id: Date: Sun, 3 Apr 2016 21:25:37 -0700 To: FreeBSD Toolchain , freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 04:25:41 -0000 For an amd64 -> armv7a (rpi2 targeting) cross-compile the code > # $FreeBSD: head/lib/libsysdecode/Makefile 295931 2016-02-23 20:00:55Z = jhb $ >=20 > . . . > ioctl.c: mkioctls > env MACHINE=3D${MACHINE} CPP=3D"${CPP}" \ > /bin/sh ${.CURDIR}/mkioctls ${DESTDIR}${INCLUDEDIR} > = ${.TARGET} (with its use of CPP instead of the XCPP) got: > --- all_subdir_lib/libsysdecode --- > --- ioctl.c --- > env MACHINE=3Darm CPP=3D"/usr/bin/clang-cpp" /bin/sh = /usr/src/lib/libsysdecode/mkioctls = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include > ioctl.c > . . . > --- all_subdir_lib/libsysdecode --- > In file included from :17: > In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/dev/nvme/nvme.h:36: > In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/sys/param.h:135: > In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/param.h:49: > = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/acle-compat.h= :182:4: error: Unable to determine architecture version. > # error Unable to determine architecture version. > ^ In my case I had the following in the in-use src.conf in order to = control the cross compile specifics: > XCC=3D/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > XCXX=3D/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > XCPP=3D/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access (I've been doing such for a long time but only just progressed to a 11.0 = source vintage with libsoft involved.) Even if I'm out of bounds for technique in some way I expect that > ioctl.c: mkioctls > env MACHINE=3D${MACHINE} CPP=3D"${CPP}" \ > /bin/sh ${.CURDIR}/mkioctls ${DESTDIR}${INCLUDEDIR} > = ${.TARGET} is not doing everything it should to have the full context needed for . = . ./machine/acle-compat.h . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Apr 4 04:48:27 2016 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 07D23AEC719 for ; Mon, 4 Apr 2016 04:48:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 CDF161AAC for ; Mon, 4 Apr 2016 04:48:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ig0-x229.google.com with SMTP id ma7so73154961igc.0 for ; Sun, 03 Apr 2016 21:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=7aOEOpNPmYLiTiqiKBSHa8jD1fI8K/0nsRoau8MDs70=; b=qEALOkA4B/BxzH16wMaZUYAVs0SbKey1NqFaZ/2P3PhPn8QR6IbDCHVsDF/WtMefdW rAQjT0/5CG4TCUjU76v7k9siox+Y2ph7gAl5UoohP8oaoEmHgs5VKW0qxHX6l36M4sJ4 4fVPcV9PpMKx9NqI/ddG0RLQIwQUAbLKDOpaellnzJ+WaWgWlyPiKzw1P/iW1mBngyn2 r+zTSfwLXbyUfTlnnbJnI+B64kVlmgrdEqlnrQGDirVSGCp59/9E9LbV4IL46vJzhyhT 8wu2ywTThTwzC/ajsdP/U7ibOcdtRPcwQGNzZlGHbOYfb+cOidYCcnMFv5vVEUXxX8yP YC2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=7aOEOpNPmYLiTiqiKBSHa8jD1fI8K/0nsRoau8MDs70=; b=Bsu6LHvxJ4d0wjU4hXNcLZ3fsmu5vxpvo2UoJqsOsv0gWMDik5B5Q+5JNvv2LtdP3b vOirKTSOjxnVs094s+UmfNNULLdxxX1ppsKO5R/nVX8sLzAEcGY7COxvFqQhtDLoguc1 6aKFXGnD8BX9gQCjlFA857Rw1/ABSTyHGJegwmLT+bNhUuk6UuBdxhYygJXIsRovBP6G ZogN3F+t/M6mWRW6k4k7qznrxQU9/HDXpJbeoZytu5hlV4mABkj6wz0Syep+nwCyUwYm fhLV1SCJU/PpUeViW1yhFgT9xa09sDgybkmas7MlQ6s7ykiBYUD2jjnUchRsq9Iun9ob /ejw== X-Gm-Message-State: AD7BkJK9TgEs70SeKxnLrVQoWQA2I+/NKA9kEx8g50LS84eFpgttB6ISAAkZ5+ModMOIoUpilUOhchp234d9vg== MIME-Version: 1.0 X-Received: by 10.50.108.108 with SMTP id hj12mr8130499igb.57.1459745305925; Sun, 03 Apr 2016 21:48:25 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.194.3 with HTTP; Sun, 3 Apr 2016 21:48:25 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: References: Date: Sun, 3 Apr 2016 22:48:25 -0600 X-Google-Sender-Auth: LA95CfgVlGcao6aQeXbvNrxy4o0 Message-ID: Subject: Re: 11.0: head/lib/libsysdecode/Makefile for . . ./libsoft/usr/include uses CPP when XCPP needed? From: Warner Losh To: Mark Millard Cc: FreeBSD Toolchain , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 04:48:27 -0000 On Sun, Apr 3, 2016 at 10:25 PM, Mark Millard wrote: > For an amd64 -> armv7a (rpi2 targeting) cross-compile the code > > > # $FreeBSD: head/lib/libsysdecode/Makefile 295931 2016-02-23 20:00:55Z > jhb $ > > > > . . . > > ioctl.c: mkioctls > > env MACHINE=${MACHINE} CPP="${CPP}" \ > > /bin/sh ${.CURDIR}/mkioctls ${DESTDIR}${INCLUDEDIR} > > ${.TARGET} > > (with its use of CPP instead of the XCPP) got: > > > --- all_subdir_lib/libsysdecode --- > > --- ioctl.c --- > > env MACHINE=arm CPP="/usr/bin/clang-cpp" /bin/sh > /usr/src/lib/libsysdecode/mkioctls > /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include > ioctl.c > > . . . > > --- all_subdir_lib/libsysdecode --- > > In file included from :17: > > In file included from > /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/dev/nvme/nvme.h:36: > > In file included from > /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/sys/param.h:135: > > In file included from > /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/param.h:49: > > > /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/acle-compat.h:182:4: > error: Unable to determine architecture version. > > # error Unable to determine architecture version. > > ^ > > In my case I had the following in the in-use src.conf in order to control > the cross compile specifics: > > > XCC=/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi -march=armv7a > -mcpu=cortex-a7 -mno-unaligned-access > > XCXX=/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi > -march=armv7a -mcpu=cortex-a7 -mno-unaligned-access > > XCPP=/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi > -march=armv7a -mcpu=cortex-a7 -mno-unaligned-access > > > (I've been doing such for a long time but only just progressed to a 11.0 > source vintage with libsoft involved.) > > Even if I'm out of bounds for technique in some way I expect that > > > ioctl.c: mkioctls > > env MACHINE=${MACHINE} CPP="${CPP}" \ > > /bin/sh ${.CURDIR}/mkioctls ${DESTDIR}${INCLUDEDIR} > > ${.TARGET} > > is not doing everything it should to have the full context needed for . . > ./machine/acle-compat.h . > It's gotta be upstream. XCPP XCC and XCXX are all exclusive to Makefile.inc1. It's up to it to sort out the rest... And none of the X{AR,AS,LD,etc} are defined, so there's bound to be an impedance mismatch. :) In the past when I've seen this it's been due to some kind of variable contamination, perhaps one that's not otherwise known... Warner From owner-freebsd-toolchain@freebsd.org Mon Apr 4 05:22:39 2016 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 F0398B01576 for ; Mon, 4 Apr 2016 05:22:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (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 B598417DD for ; Mon, 4 Apr 2016 05:22:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26216 invoked from network); 4 Apr 2016 05:22:38 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 4 Apr 2016 05:22:38 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.2) with SMTP; Mon, 04 Apr 2016 01:22:42 -0400 (EDT) Received: (qmail 12188 invoked from network); 4 Apr 2016 05:22:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 4 Apr 2016 05:22:41 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 9FAB8B1E001; Sun, 3 Apr 2016 22:22:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0: head/lib/libsysdecode/Makefile for . . ./libsoft/usr/include uses CPP when XCPP needed? From: Mark Millard In-Reply-To: Date: Sun, 3 Apr 2016 22:22:36 -0700 Cc: FreeBSD Toolchain , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warner Losh X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 05:22:40 -0000 On 2016-Apr-3, at 9:48 PM, Warner Losh wrote: >=20 > On Sun, Apr 3, 2016 at 10:25 PM, Mark Millard = wrote: > For an amd64 -> armv7a (rpi2 targeting) cross-compile the code >=20 > > # $FreeBSD: head/lib/libsysdecode/Makefile 295931 2016-02-23 = 20:00:55Z jhb $ > > > > . . . > > ioctl.c: mkioctls > > env MACHINE=3D${MACHINE} CPP=3D"${CPP}" \ > > /bin/sh ${.CURDIR}/mkioctls ${DESTDIR}${INCLUDEDIR} = > ${.TARGET} >=20 > (with its use of CPP instead of the XCPP) got: >=20 > > --- all_subdir_lib/libsysdecode --- > > --- ioctl.c --- > > env MACHINE=3Darm CPP=3D"/usr/bin/clang-cpp" /bin/sh = /usr/src/lib/libsysdecode/mkioctls = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include > ioctl.c > > . . . > > --- all_subdir_lib/libsysdecode --- > > In file included from :17: > > In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/dev/nvme/nvme.h:36: > > In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/sys/param.h:135: > > In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/param.h:49: > > = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/acle-compat.h= :182:4: error: Unable to determine architecture version. > > # error Unable to determine architecture version. > > ^ >=20 > In my case I had the following in the in-use src.conf in order to = control the cross compile specifics: >=20 > > XCC=3D/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > > XCXX=3D/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > > XCPP=3D/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access >=20 >=20 > (I've been doing such for a long time but only just progressed to a = 11.0 source vintage with libsoft involved.) >=20 > Even if I'm out of bounds for technique in some way I expect that >=20 > > ioctl.c: mkioctls > > env MACHINE=3D${MACHINE} CPP=3D"${CPP}" \ > > /bin/sh ${.CURDIR}/mkioctls ${DESTDIR}${INCLUDEDIR} = > ${.TARGET} >=20 > is not doing everything it should to have the full context needed for = . . ./machine/acle-compat.h . >=20 > It's gotta be upstream. XCPP XCC and XCXX are all exclusive to = Makefile.inc1. It's up to it to sort out the > rest... And none of the X{AR,AS,LD,etc} are defined, so there's bound = to be an impedance mismatch. :) > In the past when I've seen this it's been due to some kind of variable = contamination, perhaps one that's > not otherwise known... >=20 > Warner For reference the src.conf used for amd64 -> arm is: > KERNCONF=3DRPI2-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3Darmv6 > .export TARGET_ARCH > .endif > # > WITH_LIBSOFT=3D > WITH_FAST_DEPEND=3D > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_LLDB=3D > WITH_CLANG_EXTRAS=3D > WITH_BOOT=3D > # > WITHOUT_LIB32=3D > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_CLANG_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > .if ${.MAKE.LEVEL} =3D=3D 0 > XCC=3D/usr/bin/clang -target ${TARGET_ARCH}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > XCXX=3D/usr/bin/clang++ -target ${TARGET_ARCH}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > XCPP=3D/usr/bin/clang-cpp -target ${TARGET_ARCH}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > .export XCC > .export XCXX > .export XCPP > .endif > # > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3D/usr/bin/clang > CXX=3D/usr/bin/clang++ > CPP=3D/usr/bin/clang-cpp > .export CC > .export CXX > .export CPP > .endif =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Apr 4 06:18:59 2016 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 3840CB02A54 for ; Mon, 4 Apr 2016 06:18:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (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 E277D1DC2 for ; Mon, 4 Apr 2016 06:18:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19528 invoked from network); 4 Apr 2016 06:19:19 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 4 Apr 2016 06:19:19 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.2) with SMTP; Mon, 04 Apr 2016 02:19:20 -0400 (EDT) Received: (qmail 20329 invoked from network); 4 Apr 2016 06:19:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 4 Apr 2016 06:19:20 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 193E7B1E001; Sun, 3 Apr 2016 23:18:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0: head/lib/libsysdecode/Makefile for . . ./libsoft/usr/include uses CPP when XCPP needed? From: Mark Millard In-Reply-To: Date: Sun, 3 Apr 2016 23:18:56 -0700 Cc: FreeBSD Toolchain , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <3A6ED16B-F941-41FC-B844-50292894D5F4@dsl-only.net> References: To: Warner Losh X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 06:18:59 -0000 The following may be suggestive of the "upstream" issue: Makefile.libcompat has things like. . . > .if ${TARGET_ARCH} =3D=3D "amd64" . . . > LIB32WMAKEFLAGS=3D \ > AS=3D"${XAS} --32" \ > LD=3D"${XLD} -m elf_i386_fbsd -Y = P,${LIBCOMPATTMP}/usr/lib32" \ > OBJCOPY=3D"${XOBJCOPY}" >=20 > .elif ${TARGET_ARCH} =3D=3D "powerpc64" . . . > LIB32WMAKEFLAGS=3D \ > LD=3D"${XLD} -m elf32ppc_fbsd" \ > OBJCOPY=3D"${XOBJCOPY}" > .endif that set up to deal with some host vs. cross distinctions. But: > # soft-fp world > .if ${TARGET_ARCH} =3D=3D "armv6" > LIBSOFTCFLAGS=3D -DCOMPAT_SOFTFP > LIBSOFTCPUFLAGS=3D -mfloat-abi=3Dsoftfp > LIBSOFTWMAKEENV=3D CPUTYPE=3Dsoft MACHINE=3Darm MACHINE_ARCH=3Darmv6 > LIBSOFTWMAKEFLAGS=3D -DCOMPAT_SOFTFP > .endif in the file has no such translations and Makefile.libcompat has no = examples of ${XCPP} anywhere. The only place that has ${XCPP} in /usr/src/Makefile* and = /usr/src/share/mk/* is Makefile.inc1 : > CROSSENV+=3D CC=3D"${XCC} ${XCFLAGS}" CXX=3D"${XCXX} ${XCFLAGS} = ${XCXXFLAGS}" \ > CPP=3D"${XCPP} ${XCFLAGS}" \ > AS=3D"${XAS}" AR=3D"${XAR}" LD=3D"${XLD}" NM=3D${XNM} = \ > OBJDUMP=3D${XOBJDUMP} OBJCOPY=3D"${XOBJCOPY}" \ > RANLIB=3D${XRANLIB} STRINGS=3D${XSTRINGS} \ > SIZE=3D"${XSIZE}" but WMAKE does not use CROSSENV. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Apr-3, at 10:22 PM, Mark Millard wrote: On 2016-Apr-3, at 9:48 PM, Warner Losh wrote: >=20 > On Sun, Apr 3, 2016 at 10:25 PM, Mark Millard = wrote: > For an amd64 -> armv7a (rpi2 targeting) cross-compile the code >=20 >> # $FreeBSD: head/lib/libsysdecode/Makefile 295931 2016-02-23 = 20:00:55Z jhb $ >>=20 >> . . . >> ioctl.c: mkioctls >> env MACHINE=3D${MACHINE} CPP=3D"${CPP}" \ >> /bin/sh ${.CURDIR}/mkioctls ${DESTDIR}${INCLUDEDIR} > = ${.TARGET} >=20 > (with its use of CPP instead of the XCPP) got: >=20 >> --- all_subdir_lib/libsysdecode --- >> --- ioctl.c --- >> env MACHINE=3Darm CPP=3D"/usr/bin/clang-cpp" /bin/sh = /usr/src/lib/libsysdecode/mkioctls = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include > ioctl.c >> . . . >> --- all_subdir_lib/libsysdecode --- >> In file included from :17: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/dev/nvme/nvme.h:36: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/sys/param.h:135: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/param.h:49: >> = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/acle-compat.h= :182:4: error: Unable to determine architecture version. >> # error Unable to determine architecture version. >> ^ >=20 > In my case I had the following in the in-use src.conf in order to = control the cross compile specifics: >=20 >> XCC=3D/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access >> XCXX=3D/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access >> XCPP=3D/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access >=20 >=20 > (I've been doing such for a long time but only just progressed to a = 11.0 source vintage with libsoft involved.) >=20 > Even if I'm out of bounds for technique in some way I expect that >=20 >> ioctl.c: mkioctls >> env MACHINE=3D${MACHINE} CPP=3D"${CPP}" \ >> /bin/sh ${.CURDIR}/mkioctls ${DESTDIR}${INCLUDEDIR} > = ${.TARGET} >=20 > is not doing everything it should to have the full context needed for = . . ./machine/acle-compat.h . >=20 > It's gotta be upstream. XCPP XCC and XCXX are all exclusive to = Makefile.inc1. It's up to it to sort out the > rest... And none of the X{AR,AS,LD,etc} are defined, so there's bound = to be an impedance mismatch. :) > In the past when I've seen this it's been due to some kind of variable = contamination, perhaps one that's > not otherwise known... >=20 > Warner For reference the src.conf used for amd64 -> arm is: > KERNCONF=3DRPI2-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3Darmv6 > .export TARGET_ARCH > .endif > # > WITH_LIBSOFT=3D > WITH_FAST_DEPEND=3D > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_LLDB=3D > WITH_CLANG_EXTRAS=3D > WITH_BOOT=3D > # > WITHOUT_LIB32=3D > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_CLANG_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > .if ${.MAKE.LEVEL} =3D=3D 0 > XCC=3D/usr/bin/clang -target ${TARGET_ARCH}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > XCXX=3D/usr/bin/clang++ -target ${TARGET_ARCH}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > XCPP=3D/usr/bin/clang-cpp -target ${TARGET_ARCH}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > .export XCC > .export XCXX > .export XCPP > .endif > # > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3D/usr/bin/clang > CXX=3D/usr/bin/clang++ > CPP=3D/usr/bin/clang-cpp > .export CC > .export CXX > .export CPP > .endif =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Apr 4 15:29:05 2016 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 8782CB02FB3 for ; Mon, 4 Apr 2016 15:29:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 270AA1D98 for ; Mon, 4 Apr 2016 15:29:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ig0-x22e.google.com with SMTP id ma7so94322326igc.0 for ; Mon, 04 Apr 2016 08:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=jOkdCTcwh4jOi+cf4H+UnIOYBAxLG/meVwyNc0/C2bU=; b=gTGsysbQT5L7KuGHrlrailFlW43xjEnkFlcatPN3IhaWsU4XuGx3Y5mRCuph+BWy4d P19Nhr9ZVm6p2TLjA2EzY12YSh74ia2Z7VyVQ2hwucmChVhDThTxThzFzHT+U5uIrW3W +vo8+Zu7n55uQtt8r0ByzWEJwUHbdGqHY3h2AGb8s6lyDIWJVUcU9Oxwx1ByqfhY3+9e fHWXUtt6kGyxP+xWVVdgUSgVEljxsDTym+vXGc21+6ukCNKiaNIumBFUztQS4emzYN68 M6O9pbv7nZghH7hnWPR55JGg1lcHBmcsM9ksWoYa0wX3/wGZmMWuYe5ndKCLNymc3Nd1 jx8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jOkdCTcwh4jOi+cf4H+UnIOYBAxLG/meVwyNc0/C2bU=; b=kv3GRMAL6GeWlO1g/duiX77TUx0bO1LxDG5XFd4BZZgCLhne83cleg2o9tJBP/HP/Y McnAuU9isCOiSVGZIA9ymC3QzaFPk/4rMvr9hx8yndw1UNX0d8xYVbcTczuAcnQAZY4r jppsRsxJbP3Oj5cvEzTpcsG4jco58Cr6QBVWDX6mXH3tXwt9sD0e+h8FdtZrPLzdYbSy FbhkYyoZwulOT1CbdpWEu7DrA1tT7BgEyYOfCNmnV5KeAXGMm8V1i3/DvwIGt6KTJxV2 IxzG86QXyJOqa6mPA0qNl+/zWwnGe5GfNNTbmIqZlC2LN6UG3ezayvlyU1QYcrOSpMUI OMfA== X-Gm-Message-State: AD7BkJKjWz4+oz1m9FPSLUCEL3dCxIzXqQQknpYbO/gZL9uDDkX5dzwdct2hyGpwqO/5W7+lo4sz/x3cU80/pg== MIME-Version: 1.0 X-Received: by 10.50.108.108 with SMTP id hj12mr10588453igb.57.1459783720931; Mon, 04 Apr 2016 08:28:40 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.194.3 with HTTP; Mon, 4 Apr 2016 08:28:40 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <3A6ED16B-F941-41FC-B844-50292894D5F4@dsl-only.net> References: <3A6ED16B-F941-41FC-B844-50292894D5F4@dsl-only.net> Date: Mon, 4 Apr 2016 09:28:40 -0600 X-Google-Sender-Auth: 4vHw8rHAOxqhX5PJEU33_K6Gka4 Message-ID: Subject: Re: 11.0: head/lib/libsysdecode/Makefile for . . ./libsoft/usr/include uses CPP when XCPP needed? From: Warner Losh To: Mark Millard Cc: FreeBSD Toolchain , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 15:29:05 -0000 On Mon, Apr 4, 2016 at 12:18 AM, Mark Millard wrote: > The following may be suggestive of the "upstream" issue: > > Makefile.libcompat has things like. . . > > > .if ${TARGET_ARCH} == "amd64" > . . . > > LIB32WMAKEFLAGS= \ > > AS="${XAS} --32" \ > > LD="${XLD} -m elf_i386_fbsd -Y > P,${LIBCOMPATTMP}/usr/lib32" \ > > OBJCOPY="${XOBJCOPY}" > > > > > .elif ${TARGET_ARCH} == "powerpc64" > . . . > > LIB32WMAKEFLAGS= \ > > LD="${XLD} -m elf32ppc_fbsd" \ > > OBJCOPY="${XOBJCOPY}" > > .endif > > that set up to deal with some host vs. cross distinctions. > > But: > > > # soft-fp world > > .if ${TARGET_ARCH} == "armv6" > > LIBSOFTCFLAGS= -DCOMPAT_SOFTFP > > LIBSOFTCPUFLAGS= -mfloat-abi=softfp > > LIBSOFTWMAKEENV= CPUTYPE=soft MACHINE=arm MACHINE_ARCH=armv6 > > LIBSOFTWMAKEFLAGS= -DCOMPAT_SOFTFP > > .endif > > in the file has no such translations and Makefile.libcompat has no > examples of ${XCPP} anywhere. > > The only place that has ${XCPP} in /usr/src/Makefile* and > /usr/src/share/mk/* is Makefile.inc1 : > Yes, X* is an invention of the top level Makefile*. I've long been uneasy about it, but haven't been able to articulate why. > > CROSSENV+= CC="${XCC} ${XCFLAGS}" CXX="${XCXX} ${XCFLAGS} > ${XCXXFLAGS}" \ > > CPP="${XCPP} ${XCFLAGS}" \ > > AS="${XAS}" AR="${XAR}" LD="${XLD}" NM=${XNM} \ > > OBJDUMP=${XOBJDUMP} OBJCOPY="${XOBJCOPY}" \ > > RANLIB=${XRANLIB} STRINGS=${XSTRINGS} \ > > SIZE="${XSIZE}" > > but WMAKE does not use CROSSENV. Maybe it got removed over time? It there's one more layer of indirection? However, I'm not sure I agree with that: We see that's it's part of WMAKEENV, which is used by WMAKE: WMAKEENV= ${CROSSENV} \ ... WMAKE= ${WMAKEENV} ${MAKE} ${WORLD_FLAGS} -f Makefile.inc1 DESTDIR=${WORLDTMP} And several others. Am I missing something or looking at old code? Warner > > > === > Mark Millard > markmi at dsl-only.net > > On 2016-Apr-3, at 10:22 PM, Mark Millard wrote: > > On 2016-Apr-3, at 9:48 PM, Warner Losh wrote: > > > > On Sun, Apr 3, 2016 at 10:25 PM, Mark Millard > wrote: > > For an amd64 -> armv7a (rpi2 targeting) cross-compile the code > > > >> # $FreeBSD: head/lib/libsysdecode/Makefile 295931 2016-02-23 20:00:55Z > jhb $ > >> > >> . . . > >> ioctl.c: mkioctls > >> env MACHINE=${MACHINE} CPP="${CPP}" \ > >> /bin/sh ${.CURDIR}/mkioctls ${DESTDIR}${INCLUDEDIR} > > ${.TARGET} > > > > (with its use of CPP instead of the XCPP) got: > > > >> --- all_subdir_lib/libsysdecode --- > >> --- ioctl.c --- > >> env MACHINE=arm CPP="/usr/bin/clang-cpp" /bin/sh > /usr/src/lib/libsysdecode/mkioctls > /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include > ioctl.c > >> . . . > >> --- all_subdir_lib/libsysdecode --- > >> In file included from :17: > >> In file included from > /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/dev/nvme/nvme.h:36: > >> In file included from > /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/sys/param.h:135: > >> In file included from > /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/param.h:49: > >> > /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/acle-compat.h:182:4: > error: Unable to determine architecture version. > >> # error Unable to determine architecture version. > >> ^ > > > > In my case I had the following in the in-use src.conf in order to > control the cross compile specifics: > > > >> XCC=/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi > -march=armv7a -mcpu=cortex-a7 -mno-unaligned-access > >> XCXX=/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi > -march=armv7a -mcpu=cortex-a7 -mno-unaligned-access > >> XCPP=/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi > -march=armv7a -mcpu=cortex-a7 -mno-unaligned-access > > > > > > (I've been doing such for a long time but only just progressed to a 11.0 > source vintage with libsoft involved.) > > > > Even if I'm out of bounds for technique in some way I expect that > > > >> ioctl.c: mkioctls > >> env MACHINE=${MACHINE} CPP="${CPP}" \ > >> /bin/sh ${.CURDIR}/mkioctls ${DESTDIR}${INCLUDEDIR} > > ${.TARGET} > > > > is not doing everything it should to have the full context needed for . > . ./machine/acle-compat.h . > > > > It's gotta be upstream. XCPP XCC and XCXX are all exclusive to > Makefile.inc1. It's up to it to sort out the > > rest... And none of the X{AR,AS,LD,etc} are defined, so there's bound > to be an impedance mismatch. :) > > In the past when I've seen this it's been due to some kind of variable > contamination, perhaps one that's > > not otherwise known... > > > > Warner > > For reference the src.conf used for amd64 -> arm is: > > > KERNCONF=RPI2-NODBG > > TARGET=arm > > .if ${.MAKE.LEVEL} == 0 > > TARGET_ARCH=armv6 > > .export TARGET_ARCH > > .endif > > # > > WITH_LIBSOFT= > > WITH_FAST_DEPEND= > > WITH_LIBCPLUSPLUS= > > WITH_BINUTILS_BOOTSTRAP= > > WITH_CLANG= > > WITH_CLANG_IS_CC= > > WITH_CLANG_FULL= > > WITH_LLDB= > > WITH_CLANG_EXTRAS= > > WITH_BOOT= > > # > > WITHOUT_LIB32= > > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP= > > WITHOUT_CLANG_BOOTSTRAP= > > WITHOUT_GCC_BOOTSTRAP= > > WITHOUT_GCC= > > WITHOUT_GNUCXX= > > # > > NO_WERROR= > > MALLOC_PRODUCTION= > > # > > WITH_DEBUG_FILES= > > # > > .if ${.MAKE.LEVEL} == 0 > > XCC=/usr/bin/clang -target ${TARGET_ARCH}--freebsd11.0-gnueabi > -march=armv7a -mcpu=cortex-a7 -mno-unaligned-access > > XCXX=/usr/bin/clang++ -target ${TARGET_ARCH}--freebsd11.0-gnueabi > -march=armv7a -mcpu=cortex-a7 -mno-unaligned-access > > XCPP=/usr/bin/clang-cpp -target ${TARGET_ARCH}--freebsd11.0-gnueabi > -march=armv7a -mcpu=cortex-a7 -mno-unaligned-access > > .export XCC > > .export XCXX > > .export XCPP > > .endif > > # > > .if ${.MAKE.LEVEL} == 0 > > CC=/usr/bin/clang > > CXX=/usr/bin/clang++ > > CPP=/usr/bin/clang-cpp > > .export CC > > .export CXX > > .export CPP > > .endif > > > === > Mark Millard > markmi at dsl-only.net > > > From owner-freebsd-toolchain@freebsd.org Mon Apr 4 17:24:18 2016 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 E17AAB038F4 for ; Mon, 4 Apr 2016 17:24:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (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 A66791481 for ; Mon, 4 Apr 2016 17:24:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23393 invoked from network); 4 Apr 2016 17:24:33 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 4 Apr 2016 17:24:33 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.2) with SMTP; Mon, 04 Apr 2016 13:24:02 -0400 (EDT) Received: (qmail 3033 invoked from network); 4 Apr 2016 17:24:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 4 Apr 2016 17:24:01 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0347B1C4078; Mon, 4 Apr 2016 10:24:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0: head/lib/libsysdecode/Makefile for . . ./libsoft/usr/include uses CPP when XCPP needed? From: Mark Millard In-Reply-To: Date: Mon, 4 Apr 2016 10:24:10 -0700 Cc: FreeBSD Toolchain , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <3A6ED16B-F941-41FC-B844-50292894D5F4@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 17:24:19 -0000 On 2016-Apr-4, at 8:28 AM, Warner Losh wrote: > However, I'm not sure I agree with that: > We see that's it's part of WMAKEENV, which is used by WMAKE: >=20 > WMAKEENV=3D ${CROSSENV} \ You are correct. I just missed it somehow when I looked. But (Makefile.inc1): (no use here of WMAKE for build${libcompat} for buildsoft) > .if !defined(NO_CLEAN) > @echo > @echo = "--------------------------------------------------------------" > @echo ">>> stage 2.1: cleaning up the object tree" > @echo = "--------------------------------------------------------------" > ${_+_}cd ${.CURDIR}; ${WMAKE} ${CLEANDIR} > .if defined(LIBCOMPAT) > ${_+_}cd ${.CURDIR}; ${LIBCOMPATWMAKE} -f Makefile.inc1 = ${CLEANDIR} > .endif > .endif . . . and separately . . . > .if defined(LIBCOMPAT) && empty(SUBDIR_OVERRIDE) > WMAKE_TGTS+=3D build${libcompat} > .endif >=20 > buildworld: buildworld_prologue ${WMAKE_TGTS} buildworld_epilogue and (Makefile.libcompat): (again no use here of WMAKE for build${libcompat} for buildsoft) (just direct use of LIBSOFTWMAKEENV and LIBSOFTWMAKEFLAGS that do not = deal with ${XCPP} at all) > # soft-fp world > .if ${TARGET_ARCH} =3D=3D "armv6" > LIBSOFTCFLAGS=3D -DCOMPAT_SOFTFP > LIBSOFTCPUFLAGS=3D -mfloat-abi=3Dsoftfp > LIBSOFTWMAKEENV=3D CPUTYPE=3Dsoft MACHINE=3Darm MACHINE_ARCH=3Darmv6 > LIBSOFTWMAKEFLAGS=3D -DCOMPAT_SOFTFP > .endif > . . . > LIBCOMPATWMAKE+=3D ${LIBCOMPATWMAKEENV} ${MAKE} = ${LIBCOMPATWMAKEFLAGS} \ > MK_MAN=3Dno MK_HTML=3Dno > . . . > build${libcompat}: .PHONY > @echo > @echo = "--------------------------------------------------------------" > @echo ">>> stage 5.1: building lib${libcompat} shim libraries" > @echo = "--------------------------------------------------------------" > . . . > ${_+_}cd ${.CURDIR}; \ > ${LIBCOMPATWMAKE} -f Makefile.inc1 -DNO_FSCHG libraries =3D=3D=3D Mark Millard markmi@dsl-only.net On 2016-Apr-4, at 8:28 AM, Warner Losh wrote: On Mon, Apr 4, 2016 at 12:18 AM, Mark Millard = wrote: The following may be suggestive of the "upstream" issue: Makefile.libcompat has things like. . . > .if ${TARGET_ARCH} =3D=3D "amd64" . . . > LIB32WMAKEFLAGS=3D \ > AS=3D"${XAS} --32" \ > LD=3D"${XLD} -m elf_i386_fbsd -Y = P,${LIBCOMPATTMP}/usr/lib32" \ > OBJCOPY=3D"${XOBJCOPY}" > > .elif ${TARGET_ARCH} =3D=3D "powerpc64" . . . > LIB32WMAKEFLAGS=3D \ > LD=3D"${XLD} -m elf32ppc_fbsd" \ > OBJCOPY=3D"${XOBJCOPY}" > .endif that set up to deal with some host vs. cross distinctions. But: > # soft-fp world > .if ${TARGET_ARCH} =3D=3D "armv6" > LIBSOFTCFLAGS=3D -DCOMPAT_SOFTFP > LIBSOFTCPUFLAGS=3D -mfloat-abi=3Dsoftfp > LIBSOFTWMAKEENV=3D CPUTYPE=3Dsoft MACHINE=3Darm MACHINE_ARCH=3Darmv6 > LIBSOFTWMAKEFLAGS=3D -DCOMPAT_SOFTFP > .endif in the file has no such translations and Makefile.libcompat has no = examples of ${XCPP} anywhere. The only place that has ${XCPP} in /usr/src/Makefile* and = /usr/src/share/mk/* is Makefile.inc1 : Yes, X* is an invention of the top level Makefile*. I've long been = uneasy about it, but haven't been able to articulate why. =20 > CROSSENV+=3D CC=3D"${XCC} ${XCFLAGS}" CXX=3D"${XCXX} ${XCFLAGS} = ${XCXXFLAGS}" \ > CPP=3D"${XCPP} ${XCFLAGS}" \ > AS=3D"${XAS}" AR=3D"${XAR}" LD=3D"${XLD}" NM=3D${XNM} = \ > OBJDUMP=3D${XOBJDUMP} OBJCOPY=3D"${XOBJCOPY}" \ > RANLIB=3D${XRANLIB} STRINGS=3D${XSTRINGS} \ > SIZE=3D"${XSIZE}" but WMAKE does not use CROSSENV. Maybe it got removed over time? It there's one more layer of = indirection? However, I'm not sure I agree with that: We see that's it's part of WMAKEENV, which is used by WMAKE: WMAKEENV=3D ${CROSSENV} \ ... WMAKE=3D ${WMAKEENV} ${MAKE} ${WORLD_FLAGS} -f Makefile.inc1 = DESTDIR=3D${WORLDTMP} And several others. Am I missing something or looking at old code? Warner =20 =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Apr-3, at 10:22 PM, Mark Millard wrote: On 2016-Apr-3, at 9:48 PM, Warner Losh wrote: > > On Sun, Apr 3, 2016 at 10:25 PM, Mark Millard = wrote: > For an amd64 -> armv7a (rpi2 targeting) cross-compile the code > >> # $FreeBSD: head/lib/libsysdecode/Makefile 295931 2016-02-23 = 20:00:55Z jhb $ >> >> . . . >> ioctl.c: mkioctls >> env MACHINE=3D${MACHINE} CPP=3D"${CPP}" \ >> /bin/sh ${.CURDIR}/mkioctls ${DESTDIR}${INCLUDEDIR} > = ${.TARGET} > > (with its use of CPP instead of the XCPP) got: > >> --- all_subdir_lib/libsysdecode --- >> --- ioctl.c --- >> env MACHINE=3Darm CPP=3D"/usr/bin/clang-cpp" /bin/sh = /usr/src/lib/libsysdecode/mkioctls = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include > ioctl.c >> . . . >> --- all_subdir_lib/libsysdecode --- >> In file included from :17: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/dev/nvme/nvme.h:36: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/sys/param.h:135: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/param.h:49: >> = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/acle-compat.h= :182:4: error: Unable to determine architecture version. >> # error Unable to determine architecture version. >> ^ > > In my case I had the following in the in-use src.conf in order to = control the cross compile specifics: > >> XCC=3D/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access >> XCXX=3D/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access >> XCPP=3D/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > > > (I've been doing such for a long time but only just progressed to a = 11.0 source vintage with libsoft involved.) > > Even if I'm out of bounds for technique in some way I expect that > >> ioctl.c: mkioctls >> env MACHINE=3D${MACHINE} CPP=3D"${CPP}" \ >> /bin/sh ${.CURDIR}/mkioctls ${DESTDIR}${INCLUDEDIR} > = ${.TARGET} > > is not doing everything it should to have the full context needed for = . . ./machine/acle-compat.h . > > It's gotta be upstream. XCPP XCC and XCXX are all exclusive to = Makefile.inc1. It's up to it to sort out the > rest... And none of the X{AR,AS,LD,etc} are defined, so there's bound = to be an impedance mismatch. :) > In the past when I've seen this it's been due to some kind of variable = contamination, perhaps one that's > not otherwise known... > > Warner For reference the src.conf used for amd64 -> arm is: > KERNCONF=3DRPI2-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3Darmv6 > .export TARGET_ARCH > .endif > # > WITH_LIBSOFT=3D > WITH_FAST_DEPEND=3D > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_LLDB=3D > WITH_CLANG_EXTRAS=3D > WITH_BOOT=3D > # > WITHOUT_LIB32=3D > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_CLANG_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > .if ${.MAKE.LEVEL} =3D=3D 0 > XCC=3D/usr/bin/clang -target ${TARGET_ARCH}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > XCXX=3D/usr/bin/clang++ -target ${TARGET_ARCH}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > XCPP=3D/usr/bin/clang-cpp -target ${TARGET_ARCH}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > .export XCC > .export XCXX > .export XCPP > .endif > # > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3D/usr/bin/clang > CXX=3D/usr/bin/clang++ > CPP=3D/usr/bin/clang-cpp > .export CC > .export CXX > .export CPP > .endif =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Apr 4 18:05:11 2016 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 67F2EB02453 for ; Mon, 4 Apr 2016 18:05:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (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 19687186A for ; Mon, 4 Apr 2016 18:05:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5915 invoked from network); 4 Apr 2016 18:05:32 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 4 Apr 2016 18:05:32 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.2) with SMTP; Mon, 04 Apr 2016 14:05:32 -0400 (EDT) Received: (qmail 5322 invoked from network); 4 Apr 2016 18:05:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 4 Apr 2016 18:05:32 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1CBC7B1E001; Mon, 4 Apr 2016 11:05:05 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0: head/lib/libsysdecode/Makefile for . . ./libsoft/usr/include uses CPP when XCPP needed? From: Mark Millard In-Reply-To: Date: Mon, 4 Apr 2016 11:05:07 -0700 Cc: FreeBSD Toolchain , freebsd-arm Message-Id: <050EC0FA-21F9-4EAB-8771-B0F6E9DEE087@dsl-only.net> References: <3A6ED16B-F941-41FC-B844-50292894D5F4@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 18:05:11 -0000 On 2016-Apr-4, at 10:24 AM, Mark Millard wrote: >=20 > On 2016-Apr-4, at 8:28 AM, Warner Losh wrote: >> However, I'm not sure I agree with that: >> We see that's it's part of WMAKEENV, which is used by WMAKE: >>=20 >> WMAKEENV=3D ${CROSSENV} \ >=20 > You are correct. I just missed it somehow when I looked. >=20 >=20 >=20 >=20 > But (Makefile.inc1): > (no use here of WMAKE for build${libcompat} for buildsoft) >=20 >> .if !defined(NO_CLEAN) >> @echo >> @echo = "--------------------------------------------------------------" >> @echo ">>> stage 2.1: cleaning up the object tree" >> @echo = "--------------------------------------------------------------" >> ${_+_}cd ${.CURDIR}; ${WMAKE} ${CLEANDIR} >> .if defined(LIBCOMPAT) >> ${_+_}cd ${.CURDIR}; ${LIBCOMPATWMAKE} -f Makefile.inc1 = ${CLEANDIR} >> .endif >> .endif > . . . and separately . . . >> .if defined(LIBCOMPAT) && empty(SUBDIR_OVERRIDE) >> WMAKE_TGTS+=3D build${libcompat} >> .endif >>=20 >> buildworld: buildworld_prologue ${WMAKE_TGTS} buildworld_epilogue >=20 > and (Makefile.libcompat): > (again no use here of WMAKE for build${libcompat} for buildsoft) > (just direct use of LIBSOFTWMAKEENV and LIBSOFTWMAKEFLAGS that do not = deal with ${XCPP} at all) >=20 >> # soft-fp world >> .if ${TARGET_ARCH} =3D=3D "armv6" >> LIBSOFTCFLAGS=3D -DCOMPAT_SOFTFP >> LIBSOFTCPUFLAGS=3D -mfloat-abi=3Dsoftfp >> LIBSOFTWMAKEENV=3D CPUTYPE=3Dsoft MACHINE=3Darm MACHINE_ARCH=3Darmv6 >> LIBSOFTWMAKEFLAGS=3D -DCOMPAT_SOFTFP >> .endif >> . . . I was interrupted and I see that I missed some macros: libcompat=3D ${LIBCOMPAT:tl} _LIBCOMPAT_MAKEVARS=3D _OBJTREE TMP CPUFLAGS CFLAGS CXXFLAGS WMAKEENV = \ WMAKEFLAGS WMAKE .for _var in ${_LIBCOMPAT_MAKEVARS} .if !empty(LIB${LIBCOMPAT}${_var}) LIBCOMPAT${_var}?=3D ${LIB${LIBCOMPAT}${_var}} .endif .endfor . . . LIBCOMPATWMAKEENV+=3D MAKEOBJDIRPREFIX=3D${LIBCOMPAT_OBJTREE} \ INSTALL=3D"sh ${.CURDIR}/tools/install.sh" \ PATH=3D${TMPPATH} \ LIBDIR=3D/usr/lib${libcompat} \ SHLIBDIR=3D/usr/lib${libcompat} \ DTRACE=3D"${LIB$COMPATDTRACE:U${DTRACE}}" LIBCOMPATWMAKEFLAGS+=3D CC=3D"${XCC} ${LIBCOMPATCFLAGS}" \ CXX=3D"${XCXX} ${LIBCOMPATCFLAGS} ${LIBCOMPATCXXFLAGS}" = \ DESTDIR=3D${LIBCOMPATTMP} \ -DNO_CPU_CFLAGS \ MK_CTF=3Dno \ -DNO_LINT \ MK_TESTS=3Dno >> LIBCOMPATWMAKE+=3D ${LIBCOMPATWMAKEENV} ${MAKE} = ${LIBCOMPATWMAKEFLAGS} \ >> MK_MAN=3Dno MK_HTML=3Dno >> . . . >> build${libcompat}: .PHONY >> @echo >> @echo = "--------------------------------------------------------------" >> @echo ">>> stage 5.1: building lib${libcompat} shim libraries" >> @echo = "--------------------------------------------------------------" >> . . . >> ${_+_}cd ${.CURDIR}; \ >> ${LIBCOMPATWMAKE} -f Makefile.inc1 -DNO_FSCHG libraries >=20 >=20 > =3D=3D=3D > Mark Millard > markmi@dsl-only.net Still no use of ${XCPP} . =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Apr-4, at 8:28 AM, Warner Losh wrote: On Mon, Apr 4, 2016 at 12:18 AM, Mark Millard = wrote: The following may be suggestive of the "upstream" issue: Makefile.libcompat has things like. . . > .if ${TARGET_ARCH} =3D=3D "amd64" . . . > LIB32WMAKEFLAGS=3D \ > AS=3D"${XAS} --32" \ > LD=3D"${XLD} -m elf_i386_fbsd -Y = P,${LIBCOMPATTMP}/usr/lib32" \ > OBJCOPY=3D"${XOBJCOPY}" >=20 > .elif ${TARGET_ARCH} =3D=3D "powerpc64" . . . > LIB32WMAKEFLAGS=3D \ > LD=3D"${XLD} -m elf32ppc_fbsd" \ > OBJCOPY=3D"${XOBJCOPY}" > .endif that set up to deal with some host vs. cross distinctions. But: > # soft-fp world > .if ${TARGET_ARCH} =3D=3D "armv6" > LIBSOFTCFLAGS=3D -DCOMPAT_SOFTFP > LIBSOFTCPUFLAGS=3D -mfloat-abi=3Dsoftfp > LIBSOFTWMAKEENV=3D CPUTYPE=3Dsoft MACHINE=3Darm MACHINE_ARCH=3Darmv6 > LIBSOFTWMAKEFLAGS=3D -DCOMPAT_SOFTFP > .endif in the file has no such translations and Makefile.libcompat has no = examples of ${XCPP} anywhere. The only place that has ${XCPP} in /usr/src/Makefile* and = /usr/src/share/mk/* is Makefile.inc1 : Yes, X* is an invention of the top level Makefile*. I've long been = uneasy about it, but haven't been able to articulate why. > CROSSENV+=3D CC=3D"${XCC} ${XCFLAGS}" CXX=3D"${XCXX} ${XCFLAGS} = ${XCXXFLAGS}" \ > CPP=3D"${XCPP} ${XCFLAGS}" \ > AS=3D"${XAS}" AR=3D"${XAR}" LD=3D"${XLD}" NM=3D${XNM} \ > OBJDUMP=3D${XOBJDUMP} OBJCOPY=3D"${XOBJCOPY}" \ > RANLIB=3D${XRANLIB} STRINGS=3D${XSTRINGS} \ > SIZE=3D"${XSIZE}" but WMAKE does not use CROSSENV. Maybe it got removed over time? It there's one more layer of = indirection? However, I'm not sure I agree with that: We see that's it's part of WMAKEENV, which is used by WMAKE: WMAKEENV=3D ${CROSSENV} \ ... WMAKE=3D ${WMAKEENV} ${MAKE} ${WORLD_FLAGS} -f Makefile.inc1 = DESTDIR=3D${WORLDTMP} And several others. Am I missing something or looking at old code? Warner =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Apr-3, at 10:22 PM, Mark Millard wrote: On 2016-Apr-3, at 9:48 PM, Warner Losh wrote: >=20 > On Sun, Apr 3, 2016 at 10:25 PM, Mark Millard = wrote: > For an amd64 -> armv7a (rpi2 targeting) cross-compile the code >=20 >> # $FreeBSD: head/lib/libsysdecode/Makefile 295931 2016-02-23 = 20:00:55Z jhb $ >>=20 >> . . . >> ioctl.c: mkioctls >> env MACHINE=3D${MACHINE} CPP=3D"${CPP}" \ >> /bin/sh ${.CURDIR}/mkioctls ${DESTDIR}${INCLUDEDIR} > = ${.TARGET} >=20 > (with its use of CPP instead of the XCPP) got: >=20 >> --- all_subdir_lib/libsysdecode --- >> --- ioctl.c --- >> env MACHINE=3Darm CPP=3D"/usr/bin/clang-cpp" /bin/sh = /usr/src/lib/libsysdecode/mkioctls = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include > ioctl.c >> . . . >> --- all_subdir_lib/libsysdecode --- >> In file included from :17: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/dev/nvme/nvme.h:36: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/sys/param.h:135: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/param.h:49: >> = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/acle-compat.h= :182:4: error: Unable to determine architecture version. >> # error Unable to determine architecture version. >> ^ >=20 > In my case I had the following in the in-use src.conf in order to = control the cross compile specifics: >=20 >> XCC=3D/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access >> XCXX=3D/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access >> XCPP=3D/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access >=20 >=20 > (I've been doing such for a long time but only just progressed to a = 11.0 source vintage with libsoft involved.) >=20 > Even if I'm out of bounds for technique in some way I expect that >=20 >> ioctl.c: mkioctls >> env MACHINE=3D${MACHINE} CPP=3D"${CPP}" \ >> /bin/sh ${.CURDIR}/mkioctls ${DESTDIR}${INCLUDEDIR} > = ${.TARGET} >=20 > is not doing everything it should to have the full context needed for = . . ./machine/acle-compat.h . >=20 > It's gotta be upstream. XCPP XCC and XCXX are all exclusive to = Makefile.inc1. It's up to it to sort out the > rest... And none of the X{AR,AS,LD,etc} are defined, so there's bound = to be an impedance mismatch. :) > In the past when I've seen this it's been due to some kind of variable = contamination, perhaps one that's > not otherwise known... >=20 > Warner For reference the src.conf used for amd64 -> arm is: > KERNCONF=3DRPI2-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3Darmv6 > .export TARGET_ARCH > .endif > # > WITH_LIBSOFT=3D > WITH_FAST_DEPEND=3D > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_LLDB=3D > WITH_CLANG_EXTRAS=3D > WITH_BOOT=3D > # > WITHOUT_LIB32=3D > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_CLANG_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > .if ${.MAKE.LEVEL} =3D=3D 0 > XCC=3D/usr/bin/clang -target ${TARGET_ARCH}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > XCXX=3D/usr/bin/clang++ -target ${TARGET_ARCH}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > XCPP=3D/usr/bin/clang-cpp -target ${TARGET_ARCH}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > .export XCC > .export XCXX > .export XCPP > .endif > # > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3D/usr/bin/clang > CXX=3D/usr/bin/clang++ > CPP=3D/usr/bin/clang-cpp > .export CC > .export CXX > .export CPP > .endif =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon Apr 4 21:02:55 2016 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 A8C1EB03A79 for ; Mon, 4 Apr 2016 21:02:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (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 59D1A12DA for ; Mon, 4 Apr 2016 21:02:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12055 invoked from network); 4 Apr 2016 21:02:53 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 4 Apr 2016 21:02:53 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.2) with SMTP; Mon, 04 Apr 2016 17:03:16 -0400 (EDT) Received: (qmail 32658 invoked from network); 4 Apr 2016 21:03:15 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 4 Apr 2016 21:03:15 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id DB1ACB1E001; Mon, 4 Apr 2016 14:02:47 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0: head/lib/libsysdecode/Makefile for . . ./libsoft/usr/include uses CPP when XCPP needed? From: Mark Millard In-Reply-To: <050EC0FA-21F9-4EAB-8771-B0F6E9DEE087@dsl-only.net> Date: Mon, 4 Apr 2016 14:02:51 -0700 Cc: FreeBSD Toolchain , freebsd-arm Message-Id: <9952A60C-C3F1-40C3-AEAE-96AF6CA6E829@dsl-only.net> References: <3A6ED16B-F941-41FC-B844-50292894D5F4@dsl-only.net> <050EC0FA-21F9-4EAB-8771-B0F6E9DEE087@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 04 Apr 2016 21:02:55 -0000 As a fix for >> --- all_subdir_lib/libsysdecode --- >> In file included from :17: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/dev/nvme/nvme.h:36: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/sys/param.h:135: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/param.h:49: >> = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/acle-compat.h= :182:4: error: Unable to determine architecture version. >> # error Unable to determine architecture version. >> ^ I tested building an amd64 -> arm cross-build based on > # svnlite diff Makefile.libcompat > Index: Makefile.libcompat > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- Makefile.libcompat (revision 297514) > +++ Makefile.libcompat (working copy) > @@ -90,6 +90,7 @@ > DTRACE=3D"${LIB$COMPATDTRACE:U${DTRACE}}" > LIBCOMPATWMAKEFLAGS+=3D CC=3D"${XCC} ${LIBCOMPATCFLAGS}" \ > CXX=3D"${XCXX} ${LIBCOMPATCFLAGS} ${LIBCOMPATCXXFLAGS}" = \ > + CPP=3D"${XCPP}" \ > DESTDIR=3D${LIBCOMPATTMP} \ > -DNO_CPU_CFLAGS \ > MK_CTF=3Dno \ and it completed without getting an "error:". So this addition to = Makefile.libcompat may be one option for a fix. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Apr-4, at 11:05 AM, Mark Millard wrote: On 2016-Apr-4, at 10:24 AM, Mark Millard > wrote: >=20 > On 2016-Apr-4, at 8:28 AM, Warner Losh > wrote: >> However, I'm not sure I agree with that: >> We see that's it's part of WMAKEENV, which is used by WMAKE: >>=20 >> WMAKEENV=3D ${CROSSENV} \ >=20 > You are correct. I just missed it somehow when I looked. >=20 >=20 >=20 >=20 > But (Makefile.inc1): > (no use here of WMAKE for build${libcompat} for buildsoft) >=20 >> .if !defined(NO_CLEAN) >> @echo >> @echo = "--------------------------------------------------------------" >> @echo ">>> stage 2.1: cleaning up the object tree" >> @echo = "--------------------------------------------------------------" >> ${_+_}cd ${.CURDIR}; ${WMAKE} ${CLEANDIR} >> .if defined(LIBCOMPAT) >> ${_+_}cd ${.CURDIR}; ${LIBCOMPATWMAKE} -f Makefile.inc1 = ${CLEANDIR} >> .endif >> .endif > . . . and separately . . . >> .if defined(LIBCOMPAT) && empty(SUBDIR_OVERRIDE) >> WMAKE_TGTS+=3D build${libcompat} >> .endif >>=20 >> buildworld: buildworld_prologue ${WMAKE_TGTS} buildworld_epilogue >=20 > and (Makefile.libcompat): > (again no use here of WMAKE for build${libcompat} for buildsoft) > (just direct use of LIBSOFTWMAKEENV and LIBSOFTWMAKEFLAGS that do not = deal with ${XCPP} at all) >=20 >> # soft-fp world >> .if ${TARGET_ARCH} =3D=3D "armv6" >> LIBSOFTCFLAGS=3D -DCOMPAT_SOFTFP >> LIBSOFTCPUFLAGS=3D -mfloat-abi=3Dsoftfp >> LIBSOFTWMAKEENV=3D CPUTYPE=3Dsoft MACHINE=3Darm MACHINE_ARCH=3Darmv6 >> LIBSOFTWMAKEFLAGS=3D -DCOMPAT_SOFTFP >> .endif >> . . . I was interrupted and I see that I missed some macros: libcompat=3D ${LIBCOMPAT:tl} _LIBCOMPAT_MAKEVARS=3D _OBJTREE TMP CPUFLAGS CFLAGS CXXFLAGS WMAKEENV = \ WMAKEFLAGS WMAKE .for _var in ${_LIBCOMPAT_MAKEVARS} .if !empty(LIB${LIBCOMPAT}${_var}) LIBCOMPAT${_var}?=3D ${LIB${LIBCOMPAT}${_var}} .endif .endfor . . . LIBCOMPATWMAKEENV+=3D MAKEOBJDIRPREFIX=3D${LIBCOMPAT_OBJTREE} \ INSTALL=3D"sh ${.CURDIR}/tools/install.sh" \ PATH=3D${TMPPATH} \ LIBDIR=3D/usr/lib${libcompat} \ SHLIBDIR=3D/usr/lib${libcompat} \ DTRACE=3D"${LIB$COMPATDTRACE:U${DTRACE}}" LIBCOMPATWMAKEFLAGS+=3D CC=3D"${XCC} ${LIBCOMPATCFLAGS}" \ CXX=3D"${XCXX} ${LIBCOMPATCFLAGS} ${LIBCOMPATCXXFLAGS}" = \ DESTDIR=3D${LIBCOMPATTMP} \ -DNO_CPU_CFLAGS \ MK_CTF=3Dno \ -DNO_LINT \ MK_TESTS=3Dno >> LIBCOMPATWMAKE+=3D ${LIBCOMPATWMAKEENV} ${MAKE} = ${LIBCOMPATWMAKEFLAGS} \ >> MK_MAN=3Dno MK_HTML=3Dno >> . . . >> build${libcompat}: .PHONY >> @echo >> @echo = "--------------------------------------------------------------" >> @echo ">>> stage 5.1: building lib${libcompat} shim libraries" >> @echo = "--------------------------------------------------------------" >> . . . >> ${_+_}cd ${.CURDIR}; \ >> ${LIBCOMPATWMAKE} -f Makefile.inc1 -DNO_FSCHG libraries >=20 >=20 > =3D=3D=3D > Mark Millard > markmi@dsl-only.net Still no use of ${XCPP} . =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Apr-4, at 8:28 AM, Warner Losh > wrote: On Mon, Apr 4, 2016 at 12:18 AM, Mark Millard > wrote: The following may be suggestive of the "upstream" issue: Makefile.libcompat has things like. . . > .if ${TARGET_ARCH} =3D=3D "amd64" . . . > LIB32WMAKEFLAGS=3D \ > AS=3D"${XAS} --32" \ > LD=3D"${XLD} -m elf_i386_fbsd -Y = P,${LIBCOMPATTMP}/usr/lib32" \ > OBJCOPY=3D"${XOBJCOPY}" >=20 > .elif ${TARGET_ARCH} =3D=3D "powerpc64" . . . > LIB32WMAKEFLAGS=3D \ > LD=3D"${XLD} -m elf32ppc_fbsd" \ > OBJCOPY=3D"${XOBJCOPY}" > .endif that set up to deal with some host vs. cross distinctions. But: > # soft-fp world > .if ${TARGET_ARCH} =3D=3D "armv6" > LIBSOFTCFLAGS=3D -DCOMPAT_SOFTFP > LIBSOFTCPUFLAGS=3D -mfloat-abi=3Dsoftfp > LIBSOFTWMAKEENV=3D CPUTYPE=3Dsoft MACHINE=3Darm MACHINE_ARCH=3Darmv6 > LIBSOFTWMAKEFLAGS=3D -DCOMPAT_SOFTFP > .endif in the file has no such translations and Makefile.libcompat has no = examples of ${XCPP} anywhere. The only place that has ${XCPP} in /usr/src/Makefile* and = /usr/src/share/mk/* is Makefile.inc1 : Yes, X* is an invention of the top level Makefile*. I've long been = uneasy about it, but haven't been able to articulate why. > CROSSENV+=3D CC=3D"${XCC} ${XCFLAGS}" CXX=3D"${XCXX} ${XCFLAGS} = ${XCXXFLAGS}" \ > CPP=3D"${XCPP} ${XCFLAGS}" \ > AS=3D"${XAS}" AR=3D"${XAR}" LD=3D"${XLD}" NM=3D${XNM} \ > OBJDUMP=3D${XOBJDUMP} OBJCOPY=3D"${XOBJCOPY}" \ > RANLIB=3D${XRANLIB} STRINGS=3D${XSTRINGS} \ > SIZE=3D"${XSIZE}" but WMAKE does not use CROSSENV. Maybe it got removed over time? It there's one more layer of = indirection? However, I'm not sure I agree with that: We see that's it's part of WMAKEENV, which is used by WMAKE: WMAKEENV=3D ${CROSSENV} \ ... WMAKE=3D ${WMAKEENV} ${MAKE} ${WORLD_FLAGS} -f Makefile.inc1 = DESTDIR=3D${WORLDTMP} And several others. Am I missing something or looking at old code? Warner =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Apr-3, at 10:22 PM, Mark Millard > wrote: On 2016-Apr-3, at 9:48 PM, Warner Losh > wrote: >=20 > On Sun, Apr 3, 2016 at 10:25 PM, Mark Millard > wrote: > For an amd64 -> armv7a (rpi2 targeting) cross-compile the code >=20 >> # $FreeBSD: head/lib/libsysdecode/Makefile 295931 2016-02-23 = 20:00:55Z jhb $ >>=20 >> . . . >> ioctl.c: mkioctls >> env MACHINE=3D${MACHINE} CPP=3D"${CPP}" \ >> /bin/sh ${.CURDIR}/mkioctls ${DESTDIR}${INCLUDEDIR} > = ${.TARGET} >=20 > (with its use of CPP instead of the XCPP) got: >=20 >> --- all_subdir_lib/libsysdecode --- >> --- ioctl.c --- >> env MACHINE=3Darm CPP=3D"/usr/bin/clang-cpp" /bin/sh = /usr/src/lib/libsysdecode/mkioctls = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include > ioctl.c >> . . . >> --- all_subdir_lib/libsysdecode --- >> In file included from :17: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/dev/nvme/nvme.h:36: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/sys/param.h:135: >> In file included from = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/param.h:49: >> = /usr/obj/clang/arm.armv6/usr/src/libsoft/usr/include/machine/acle-compat.h= :182:4: error: Unable to determine architecture version. >> # error Unable to determine architecture version. >> ^ >=20 > In my case I had the following in the in-use src.conf in order to = control the cross compile specifics: >=20 >> XCC=3D/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access >> XCXX=3D/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access >> XCPP=3D/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access >=20 >=20 > (I've been doing such for a long time but only just progressed to a = 11.0 source vintage with libsoft involved.) >=20 > Even if I'm out of bounds for technique in some way I expect that >=20 >> ioctl.c: mkioctls >> env MACHINE=3D${MACHINE} CPP=3D"${CPP}" \ >> /bin/sh ${.CURDIR}/mkioctls ${DESTDIR}${INCLUDEDIR} > = ${.TARGET} >=20 > is not doing everything it should to have the full context needed for = . . ./machine/acle-compat.h . >=20 > It's gotta be upstream. XCPP XCC and XCXX are all exclusive to = Makefile.inc1. It's up to it to sort out the > rest... And none of the X{AR,AS,LD,etc} are defined, so there's bound = to be an impedance mismatch. :) > In the past when I've seen this it's been due to some kind of variable = contamination, perhaps one that's > not otherwise known... >=20 > Warner For reference the src.conf used for amd64 -> arm is: > KERNCONF=3DRPI2-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3Darmv6 > .export TARGET_ARCH > .endif > # > WITH_LIBSOFT=3D > WITH_FAST_DEPEND=3D > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_LLDB=3D > WITH_CLANG_EXTRAS=3D > WITH_BOOT=3D > # > WITHOUT_LIB32=3D > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_CLANG_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > .if ${.MAKE.LEVEL} =3D=3D 0 > XCC=3D/usr/bin/clang -target ${TARGET_ARCH}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > XCXX=3D/usr/bin/clang++ -target ${TARGET_ARCH}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > XCPP=3D/usr/bin/clang-cpp -target ${TARGET_ARCH}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > .export XCC > .export XCXX > .export XCPP > .endif > # > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3D/usr/bin/clang > CXX=3D/usr/bin/clang++ > CPP=3D/usr/bin/clang-cpp > .export CC > .export CXX > .export CPP > .endif =3D=3D=3D Mark Millard markmi at dsl-only.net