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