11.0: head/lib/libsysdecode/Makefile for . . ./libsoft/usr/include uses CPP when XCPP needed? [Makefile.libcompat issue]

Fri Apr 15 07:48:28 UTC 2016

On 2016-Apr-14, at 1:41 PM, Bryan Drewery <bdrewery at FreeBSD.org> wrote:

> . . .Please try this patch though:
> 
> https://people.freebsd.org/~bdrewery/patches/libcompat-xcpp.diff

So far so good. . .

TARGET_ARCH=amd64 hosted on amd64: buildworld/buildkernel built without reporting any errors.

TARGET_ARCH=armv6 hosted on amd64: buildworld/buildkernel built without reporting any errors. (src.conf tailored to targeting rpi2's armv7a more specifically.)

TARGET_ARCH=powerpc hosted on amd64 having clang bootstrap a gcc 4.2.1 based buildworld/buildkernel (clang not built): built without reporting any errors.

TARGET_ARCH=powerpc hosted on powerpc having clang just buildworld (no buildkernel): built without reporting any errors. (This environment requires workarounds such as signal handling changes --and c++ exceptions do not work. I've never gotten so far as to have workarounds for buildkernel. gcc 4.2.1 not built.)

TARGET_ARCH=powerpc64 hosted on powerpc64 having a powerpc64-xtoolchain-gcc/powerpc64-gcc based buildworld/buildkernel with a LIB32 built (a system that contains an unused clang/clang++, gcc4.2.1 not built): built without reporting any errors. (Getting powerpc64-gcc to install on a powerpc64 context requires workarounds because it is not a true cross compile context. I've never had a gcc after gcc 4.2.1 build the LIB32 such that it actually worked when used.)

Still in process:

TARGET_ARCH=powerpc64 hosted on amd64 having a powerpc64-xtoolchain-gcc/power-gcc based buildworld/buildkernel with a LIB32 built (a system that contains an unused clang/clang++, gcc4.2.1 not built): Still in process. (I've never had a gcc after gcc 4.2.1 build the LIB32 such that it actually worked when used.)

TARGET_ARCH=powerpc64 hosted on powerpc64 having a powerpc64-xtoolchain-gcc/power-gcc based buildworld/buildkernel without LIB32 (and that contains an unused clang/clang++, gcc4.2.1 not built): Still in process. (Getting powerpc64-gcc to install on a powerpc64 context requires workarounds because it is not a true cross compile context.)

===
Mark Millard
markmi at dsl-only.net

Older material. . .

On 2016-Apr-14, at 2:54 PM, Mark Millard <markmi at dsl-only.net> wrote:

> This will take me a while.
> 
> I'm trying 2 or more builds, all from amd64 context:
> 
> TARGET_ARCH=amd64
> TARGET_ARCH=armv6 (with my rpi2 armv7a tailoring in src.conf)
> possibly TARGET_ARC=powerpc64 (without lib32) or powerpc (which has no lib32 or libsoft option)
> 
> I'm doing this because my personal work arounds have been to have an additional line that I'd adjust:
> 
> For TARGET_ARCH=amd64: #LIBCOMPATWMAKEFLAGS+= CPP="${XCPP}"
> For TARGET_ARCH=armv6: LIBCOMPATWMAKEFLAGS+= CPP="${XCPP}"
> 
> So: commented out vs. not. amd64 did not work with the ${XCPP} use because it depended on a not being limited to the x86 during its lib32 processing.
> 
> See https://lists.freebsd.org/pipermail/freebsd-arm/2016-April/013663.html for more information. Without the "#" for amd64 I got (grep of the log):
> 
>> ioctl.c:472:18: error: use of undeclared identifier 'CCISS_PASSTHRU32'
>> ioctl.c:1186:18: error: use of undeclared identifier 'IPMICTL_RECEIVE_MSG_32'
>> ioctl.c:1190:18: error: use of undeclared identifier 'IPMICTL_RECEIVE_MSG_TRUNC_32'
>> ioctl.c:1196:18: error: use of undeclared identifier 'IPMICTL_SEND_COMMAND_32'
>> ioctl.c:1394:18: error: use of undeclared identifier 'MPTIO_RAID_ACTION32'
>> ioctl.c:1398:18: error: use of undeclared identifier 'MPTIO_READ_CFG_HEADER32'
>> ioctl.c:1402:18: error: use of undeclared identifier 'MPTIO_READ_CFG_PAGE32'
>> ioctl.c:1406:18: error: use of undeclared identifier 'MPTIO_READ_EXT_CFG_HEADER32'
>> ioctl.c:1410:18: error: use of undeclared identifier 'MPTIO_READ_EXT_CFG_PAGE32'
>> ioctl.c:1414:18: error: use of undeclared identifier 'MPTIO_WRITE_CFG_PAGE32'
> 
> Of course since I omitted ${LIBCOMPATCFLAGS} my earlier results might not apply to your change.
> 
> I'm trying these on 11.0-CURRENT -r297769 . Let me know if I should use something more recent for some reason.
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
On 2016-Apr-14, at 1:41 PM, Bryan Drewery <bdrewery at FreeBSD.org> wrote:
> 
> On 4/6/2016 1:14 PM, Mark Millard wrote:
>> The below forwards an example of a possibly more general issue not necessarily limited to arm context of the example: in a cross compile context the host CPP is in use via Makefile.libcompat not involving "${XCPP}" and so various macro checks for the target context fail to work.
>> 
>> [The below and the material leading up to it was originally posted to freebsd-arm.]
>> 
>> ===
>> Mark Millard
>> markmi at dsl-only.net
>> 
>> On 2016-Apr-4, at 2:02 PM, Mark Millard <markmi at dsl-only.net> wrote:
>> 
>> As a fix for
>> 
>>>> --- 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.
>>>> ^
>> 
>> I tested building an amd64 -> arm cross-build based on
>> 
>>> # svnlite diff Makefile.libcompat
>>> Index: Makefile.libcompat
>>> ===================================================================
>>> --- Makefile.libcompat	(revision 297514)
>>> +++ Makefile.libcompat	(working copy)
>>> @@ -90,6 +90,7 @@
>>> 		DTRACE="${LIB$COMPATDTRACE:U${DTRACE}}"
>>> LIBCOMPATWMAKEFLAGS+= CC="${XCC} ${LIBCOMPATCFLAGS}" \
>>> 		CXX="${XCXX} ${LIBCOMPATCFLAGS} ${LIBCOMPATCXXFLAGS}" \
>>> +		CPP="${XCPP}" \
>>> 		DESTDIR=${LIBCOMPATTMP} \
>>> 		-DNO_CPU_CFLAGS \
>>> 		MK_CTF=no \
>> 
>> and it completed without getting an "error:". So this addition to Makefile.libcompat may be one option for a fix.
>> 
> 
> Yes this is needed. Please try this patch though:
> 
> https://people.freebsd.org/~bdrewery/patches/libcompat-xcpp.diff
> 
> 
> -- 
> Regards,
> Bryan Drewery
> 