Re: WITH_CLANG_BOOTSTRAP= for TARGET_ARCH=powerpc64 but bound to devel/powerpc64-binutils : can such be done?

2016-11-27 Thread Mark Millard 
[Looks like I misread something so. . .]

On 2016-Nov-27, at 4:34 PM, Mark Millard  wrote:

> Currently head has switched to clang 3.9.0 but my
> TARGET_ARCH=powerpc64for clang experiments for buildworld are blocked
> by WITH_BINUTILS_BOOTSTRAP= 's ld stopping the buildworld via failing
> asserts.
> 
> What I'd like to do is build the bootstrap clang but bound to a
> devel/powerpc64-binutils vintage to see if that works. So binutils
> being "cross tool chain" (even when directly invoked by clang) but
> clang itself not being cross tool chain but bootstrapped?
> 
> (elftoolchain may need to be considered with binutils.)
> 
> Do you know if there is a way for me to make assignments in a
> SRC_ENV_CONF file that might enable such a combination? Or
> do I need to modify the build environment to be non-standard?
> 
> So far in my reading /usr/src/Makefile.inc1 I've not seen any
> combination of settings that look like it would go through and
> work for what I've described here.

I misread something and the following seems to have worked:
(I tend to be explicit about some things that I do not need
to be in such files: it helps em remember and understand some
issues.)

# more ~/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host 
TO_TYPE=powerpc64
TOOLS_TO_TYPE=${TO_TYPE}
VERSION_CONTEXT=12.0
#
KERNCONF=GENERIC64vtsc-NODBG
TARGET=powerpc
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITH_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
WITH_LIBCPLUSPLUS=
WITHOUT_BINUTILS_BOOTSTRAP=
WITH_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLDB=
#
WITH_BOOT=
# world32/usr/src/lib/csu/powerpc/crti.o got:
# csu/powerpc/crti.S:34:13: error: unexpected token in memory operand
# csu/powerpc/crti.S:35:2: error: invalid instruction mnemonic 'mflr'
# and the like. So avoid LIB32.
WITHOUT_LIB32=
#
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_DEBUG_FILES=
#
#
# For TO (so-called "cross") stages . . .
# So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . .
# TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . .
#
CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
.if ${.MAKE.LEVEL} == 0
XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
#NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
.export XAS
.export XAR
.export XLD
.export XNM
.export XOBJCOPY
.export XOBJDUMP
.export XRANLIB
.export XSIZE
.export XSTRINGS
.endif
#
#
# From based on clang (via system). . .
#
.if ${.MAKE.LEVEL} == 0
CC=/usr/bin/clang
CXX=/usr/bin/clang++
CPP=/usr/bin/clang-cpp
.export CC
.export CXX
.export CPP
.endif

I have not tested what the buildworld produced yet.

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

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

head -r309179 clang 3.9.0 for TARGET_ARCH=powerpc64 with devel/powerpc64-binutils used: WITH_LIB32= related assembler source rejected. . .

2016-11-27 Thread Mark Millard 
[Note: ld from WITH_BINTOOLS_BOOTSTRAP= for buildworld fails and stops
buildworld. This explains the use of devel/powerpc64-binutils below.]

Using clang 3.9.0 for TARGET_ARCH=powerpc64 with
devel/powerpc64-binutils (of an appropriate vintage) apparently
requires r1 instead of 1 for a register name --and so on.

It turns out that trying to use WITH_LIB32= for TARGET_ARCH=powerpc64
with devel/powerpc64-binutils runs into assembler source files that
are rejected for this reason.

There are also complaints about invalid mnemonics (mflr and mr).

The error reports:
(Other files may well have the same sorts of problems.)

> --- lib/csu__L ---
> Building 
> /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/world32/usr/src/lib/csu/powerpc/crti.o
> . . .
> --- crti.o ---
> /usr/src/lib/csu/powerpc/crti.S:34:13: error: unexpected token in memory 
> operand
>  stwu 1,-16(1)
> ^
> /usr/src/lib/csu/powerpc/crti.S:35:2: error: invalid instruction mnemonic 
> 'mflr'
>  mflr 0
>  ^
> /usr/src/lib/csu/powerpc/crti.S:36:12: error: unexpected token in memory 
> operand
>  stw 31,12(1)
>^
> /usr/src/lib/csu/powerpc/crti.S:37:11: error: unexpected token in memory 
> operand
>  stw 0,20(1)
>   ^
> /usr/src/lib/csu/powerpc/crti.S:38:2: error: invalid instruction mnemonic 'mr'
>  mr 31,1
>  ^
> /usr/src/lib/csu/powerpc/crti.S:45:13: error: unexpected token in memory 
> operand
>  stwu 1,-16(1)
> ^
> /usr/src/lib/csu/powerpc/crti.S:46:2: error: invalid instruction mnemonic 
> 'mflr'
>  mflr 0
>  ^
> /usr/src/lib/csu/powerpc/crti.S:47:12: error: unexpected token in memory 
> operand
>  stw 31,12(1)
>^
> /usr/src/lib/csu/powerpc/crti.S:48:11: error: unexpected token in memory 
> operand
>  stw 0,20(1)
>   ^
> /usr/src/lib/csu/powerpc/crti.S:49:2: error: invalid instruction mnemonic 'mr'
>  mr 31,1
>  ^
> *** [crti.o] Error code 1
> 
> make[5]: stopped in /usr/src/lib/csu/powerpc
> .ERROR_TARGET='crti.o'
> .ERROR_META_FILE='/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/world32/usr/src/lib/csu/powerpc/crti.o.meta'
> .MAKE.LEVEL='5'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> .CURDIR='/usr/src/lib/csu/powerpc'
> .MAKE='make'
> .OBJDIR='/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/world32/usr/src/lib/csu/powerpc'
> .TARGETS='all'
> DESTDIR='/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/lib32'
> LD_LIBRARY_PATH=''
> MACHINE='powerpc'
> MACHINE_ARCH='powerpc'
> MAKEOBJDIRPREFIX='/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/world32'
> MAKESYSPATH='/usr/src/share/mk'
> MAKE_VERSION='20160818'
> PATH='/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp/legacy/bin:/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
> SRCTOP='/usr/src'
> OBJTOP='/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/world32/usr/src'
> .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
> /usr/src/share/mk/src.sys.env.mk 
> /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host 
> /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk 
> /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk 
> /usr/src/share/mk/src.sys.mk /dev/null /usr/src/lib/csu/powerpc/Makefile 
> /usr/src/share/mk/bsd.lib.mk /usr/src/share/mk/bsd.init.mk 
> /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk 
> /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk 
> /usr/src/lib/csu/powerpc/../Makefile.inc 
> /usr/src/lib/csu/powerpc/../../Makefile.inc /usr/src/share/mk/bsd.own.mk 
> /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.libnames.mk 
> /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/src.opts.mk 
> /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk 
> /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk 
> /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk /us
 r/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk 
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk 
/usr/src/share/mk/bsd.sys.mk'
> .PATH='. /usr/src/lib/csu/powerpc /usr/src/lib/csu/powerpc/../common'
> --- lib/libc_nonshared__L ---
> Building 
> /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/world32/usr/src/lib/libc_nonshared/iconv.o
> --- lib/csu__L ---
> 1 error


The .meta report:

> # more 
> /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/world32/usr/src/lib/csu/powerpc/crti.o.meta
> # Meta data file 
>

[Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference

2016-11-27 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214863

Jan Beich (mail not working)  changed:

   What|Removed |Added

 CC||port...@freebsd.org
 Attachment #177468||maintainer-approval?(portmg
  Flags||r...@freebsd.org)

--- Comment #2 from Jan Beich (mail not working)  ---
Created attachment 177468
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=177468=edit
gcc48 workaround

Maybe dangerous if USES=compiler:gcc-c++11-lib is mixed with USES=fortran in
dependencies. I've only tested direct consumers. graphics/GraphicsMagick had to
be patched to avoid breaking science/gnudatalanguage: http://sprunge.us/bMYN

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

WITH_CLANG_BOOTSTRAP= for TARGET_ARCH=powerpc64 but bound to devel/powerpc64-binutils : can such be done?

2016-11-27 Thread Mark Millard 
Currently head has switched to clang 3.9.0 but my
TARGET_ARCH=powerpc64for clang experiments for buildworld are blocked
by WITH_BINUTILS_BOOTSTRAP= 's ld stopping the buildworld via failing
asserts.

What I'd like to do is build the bootstrap clang but bound to a
devel/powerpc64-binutils vintage to see if that works. So binutils
being "cross tool chain" (even when directly invoked by clang) but
clang itself not being cross tool chain but bootstrapped?

(elftoolchain may need to be considered with binutils.)

Do you know if there is a way for me to make assignments in a
SRC_ENV_CONF file that might enable such a combination? Or
do I need to modify the build environment to be non-standard?

So far in my reading /usr/src/Makefile.inc1 I've not seen any
combination of settings that look like it would go through and
work for what I've described here.

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

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

[Bug 214855] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based cross build: powerpc.powerpc64/usr/src/tmp/usr/bin/ld: BFD 2.17.50 [FreeBSD] 2007-07-03 internal error

2016-11-27 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214855

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|freebsd-toolchain@FreeBSD.o
   ||rg

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 214862] head -r309197 clang 3.9.0 vs. TARGET_ARCH=powerpc: fsck_ufs and "df -m" are example failures: __floatdidf gets SIGSEGV's in both of them

2016-11-27 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214862

Mark Linimon  changed:

   What|Removed |Added

   Keywords||regression
   Assignee|freebsd-b...@freebsd.org|freebsd-toolchain@FreeBSD.o
   ||rg

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"