On 06.12.15 22:34, Mark Millard wrote:
[I picked the lists that I did because powerpc64-gcc is the external
toolchain created to allow modern powerpc64 builds.]
For the powerpc64-gcc 5.2 vintages. . . (using my environment's path
as an example)
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.2.0/gcc/config/rs6000/freebsd64.h
has:
/* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults
instead. */ #undef WCHAR_TYPE #define WCHAR_TYPE
(TARGET_64BIT ? "int" : "long int") #undef WCHAR_TYPE_SIZE #define
WCHAR_TYPE_SIZE 32
That type in quotes ends up being the base type for L". . ."
notation, for example. Probably the char notation as well (L'?').
For FreeBSD Char compatibility in a powerpc64 lib32 context that
"long int" should effectively instead be "int", making the
conditional above technically unnecessary.
This blocks compiling lib32 source code that uses such notations as
L". . .": "long int" is not compatible with FreeBSD's Char in the
powerpc64 environment's 32 bit environment. Some compiler message are
explicit about the base types of pointers that result for the
mismatches: that is how I know that "long int" is in use for L". . ."
and "int" is the other base type involved.
(Yes, freebsd64.h appears to be used for lib32, at least on
powerpc64. By contrast freebsd.h agrees for the WCHAR_TYPE_SIZE but
only undef's WCHAR_TYPE, presuming gcc defaults are correct for
FreeBSD as far as the type goes. It might need a more explicit type
to be sure of a Char match for that freebsd.h file's context.)
The 4.9 vintages of powerpc64-gcc were messed up the same way, as was
noted at the time.
I'll take care.
Andreas
_______________________________________________
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"
