On 2017-Apr-28, at 5:24 PM, Mark Millard <markmi at dsl-only.net> wrote:
> On 2017-Apr-28, at 3:27 PM, Mark Millard <markmi at dsl-only.net> wrote: > >> Just FYI: >> >> https://reviews.freebsd.org/D10537 may help with powerpc64-gcc >> slave ports (and powerpc64-gcc itself) when they are built on >> the type of machine that they target. >> >> As of devel/*binutils -r436732 and -r432733 (the update >> to 2.28) many things are broken for linking with debug >> information that were not before (for example). It turns >> out to be because of a change in return code for reporting >> issues for the cases I know about: the new return code >> stops the build (and the return code is likely appropriate >> long term as I understand). For example a formerly ignored >> debug information issue now blocks various builds when a >> (modern) binutils is involved. >> >> [Because of this I've been reverting devel/*binutils >> to -r436731 each time I update the revision of >> /usr/ports.] >> >> As of ports head -r439263 with reverting >> devel/*binutils to -r436731 and the patch >> from D10537 I tested building the following >> earlier today as part of reviewing D10537: >> >> amd64: built amd64-gcc powerpc64-gcc aarch64-gcc >> powerpc64: built powerpc64-gcc >> aarch64: built aarch64-gcc >> (Note: aarch64 is using -mcpu=cortex-a53 explicitly.) >> >> Context: head -r317015 in each case. >> (WITH_LLD_IS_LD= was used on aarch64.) >> (powerpc64 is system-clang/libc++ based, used >> devel/*binutils) >> >> If the information would be useful I could try >> some other combinations under the patch and >> the older binutils for comparison. (That does >> not say when anyone might use the information.) >> >> I also have access to armv7. (In this context >> I normally use -mcpu=cortex-a7 explicitly.) >> So I could try that type of host as well. >> >> I do not have access to mips, mips64, riscv, sparc64 >> so they could be targets but not hosts in my tests: >> always cross-builds. >> >> I have access to powerpc but currently am not well >> set up to use it without rebuilding it as gcc 4.2.1 >> based for buildworld, not just buildkernel. (clang >> generates bad stack handling for some contexts for >> 32-bit powerpc.) > > I tried building devel/amd64-gcc on a powerpc64 > head -r317015 system that was built with clang > and libc++ and has clang as its system compiler. > /usr/ports as of -r439263 but devel/*binutils as > of -r436731 (so 2.27 instead of 2.2.8). The result > was the "=a" problem for the clang based build: > > /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i386/cpuid.h:223:3: > error: invalid output constraint '=a' in asm > __cpuid (__ext, __eax, __ebx, __ecx, __edx); > ^ > /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i386/cpuid.h:165:7: > note: expanded from macro '__cpuid' > : "=a" (a), "=b" (b), "=c" (c), "=d" (d) \ > . . . (other such messages) . . . > In file included from > /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/cppspec.c/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i386/driver-i386.c:554::225: > error: invalid output constraint '=a' in asm > . . . > : "=a" (eax), "=d" (edx) > ^ > . . . > > So this system-clang context on powerpc64 is like -r439595 > reports for building devel/amd64-gcc on aarch64: > > +BROKEN_aarch64= error: invalid output constraint '=a' in asm > > head/devel/amd64-gcc/Makefile only says: > > BROKEN_powerpc64= Does not build > > but it is like on aarch64 --at least when system-clang > compiler that is in use. > > The compiler command lines were: > > c++ -std=gnu++98 -fno-PIE -c -O2 -pipe -B/usr/local/bin/ -DLIBICONV_PLUG -g > -fno-strict-aliasing -B/usr/local/bin/ -DLIBICONV_PLUG -DIN_GCC > -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables > -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual > -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long > -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. > -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc > -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/. > -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../include > -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcpp/include > -I/usr/local/include > -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libdecnumber > > -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libdecnumber/dpd > -I../libdecnumber > -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libbac kt > race -B/usr/local/bin/ -DLIBICONV_PLUG -o driver-i386.o -MT driver-i386.o > -MMD -MP -MF ./.deps/driver-i386.TPo > /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i386/driver-i386.c > > c++ -std=gnu++98 -fno-PIE -c -O2 -pipe -B/usr/local/bin/ -DLIBICONV_PLUG -g > -fno-strict-aliasing -B/usr/local/bin/ -DLIBICONV_PLUG -DIN_GCC > -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables > -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual > -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long > -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -Ic-family > -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc > -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family > -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../include > -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcpp/include > -I/usr/local/include > -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libdecnumber > > -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libdecnumber/dpd > -I../libdecnumber > -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0 /g > cc/../libbacktrace -B/usr/local/bin/ -DLIBICONV_PLUG -o c-family/cppspec.o > -MT c-family/cppspec.o -MMD -MP -MF c-family/.deps/cppspec.TPo > /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/cppspec.c > > It will be a fairly long time before the aarch64 > context gets to this point in a devel/adm64-gcc > build, although I expect a replication of the > reported behavior for building devel/amd64-gcc . Based on the aarch64 context specified in the original note (system version, /usr/ports versions, and the like). . . The following built fine: ===>>> The following actions were performed: Re-installation of aarch64-none-elf-gcc-6.3.0 Installation of devel/arm-none-eabi-binutils (arm-none-eabi-binutils-2.27_5,1) Installation of devel/arm-none-eabi-gcc (arm-none-eabi-gcc-6.3.0) But devel/arm-none-eabi-gcc492 then conflicts with devel/arm-none-eabi-gcc : ===> Registering installation for arm-none-eabi-gcc492-4.9.2_2 Installing arm-none-eabi-gcc492-4.9.2_2... pkg-static: arm-none-eabi-gcc492-4.9.2_2 conflicts with arm-none-eabi-gcc-6.3.0 (installs files into the same place). Problematic file: /usr/local/bin/arm-none-eabi-c++ *** Error code 70 So to test devel/arm-none-eabi-gcc492 fully requires that any pre-installed devel/arm-none-eabi-gcc first be deleted/removed. There is every indication that absent the conflict devel/arm-none-eabi-gcc492 would have installed just fine and it did build to the point of installing. So the following did not have package problems: devel/aarch64-none-elf-gcc-6.3.0 devel/arm-none-eabi-gcc But that last was given that devel/arm-none-eabi-gcc492 had not been installed. I still have the following to go on aarch64 (cortex-a53): devel/powerpc64-gcc devel/riscv64-gcc devel/sparc64-gcc devel/amd64-gcc I also have armv7 (cortex-a7) attempting: devel/arm-none-eabi-gcc492 devel/amd64-gcc === 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"
