Date: Mon, 4 Apr 2016 11:05:07 -0700 From: Mark Millard <markmi@dsl-only.net> To: Warner Losh <imp@bsdimp.com> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: 11.0: head/lib/libsysdecode/Makefile for . . ./libsoft/usr/include uses CPP when XCPP needed? Message-ID: <050EC0FA-21F9-4EAB-8771-B0F6E9DEE087@dsl-only.net> In-Reply-To: <B6B88406-A0AE-4704-9343-F65CF8DDBC5D@dsl-only.net> References: <D8803949-18C1-4B17-981F-DAD5A2DEDCE8@dsl-only.net> <CANCZdfo3Gdf0QF64hfn_WJzxhPOwJk6yMB3qEkDi8tfEpRRveg@mail.gmail.com> <B222BAE7-FD73-4F54-8C31-E982B6FCA718@dsl-only.net> <3A6ED16B-F941-41FC-B844-50292894D5F4@dsl-only.net> <CANCZdfqX8d-DZ-Y%2B%2BDFjsP7L8M_xFTvFLknxgGLSf_zO-wSfdA@mail.gmail.com> <B6B88406-A0AE-4704-9343-F65CF8DDBC5D@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Apr-4, at 10:24 AM, Mark Millard <markmi at dsl-only.net> wrote:
>=20
> On 2016-Apr-4, at 8:28 AM, Warner Losh <imp at bsdimp.com> 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 <imp@bsdimp.com> wrote:
On Mon, Apr 4, 2016 at 12:18 AM, Mark Millard <markmi@dsl-only.net> =
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 <markmi at dsl-only.net> wrote:
On 2016-Apr-3, at 9:48 PM, Warner Losh <imp bsdimp.com> wrote:
>=20
> On Sun, Apr 3, 2016 at 10:25 PM, Mark Millard <markmi dsl-only.net> =
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 <stdin>: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?050EC0FA-21F9-4EAB-8771-B0F6E9DEE087>