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) >>> _at__at_ -90,6 +90,7 _at__at_ >>> 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 >Received on Fri Apr 15 2016 - 05:48:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:04 UTC