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

2016-04-15 Thread Mark Millard 
On 2016-Apr-14, at 1:41 PM, Bryan Drewery  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  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  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  wrote:
>> 
>> 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

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

2016-04-14 Thread Mark Millard 
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  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  wrote:
> 
> 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
>> ===
>> --- 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


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

2016-04-14 Thread Bryan Drewery 
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  wrote:
> 
> 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
>> ===
>> --- 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



signature.asc
Description: OpenPGP digital signature

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

2016-04-06 Thread Mark Millard 
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  wrote:

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
> ===
> --- 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.

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


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"