On 2017-Apr-28, at 6:10 PM, Mark Millard <markmi at dsl-only.net> wrote:
> 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/../libba c > 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 The armv7 attempt at devel/amd64-gcc also got the "=a" problem, such as: /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i386/driver-i386.c:608:2: error: invalid output constraint '=a' in asm __cpuid (0x80000002, name, 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) \ ^ So this is like what devel/powerpc64-gcc got in a system-clang based context --and armv7 is again based on clang so the message is from clang. (I expect aarch64 to get the same thing once it tries devel/amd64-gcc since -r439595 reports such for aarch64.) Not that this is different from -r439595's report, which said for devel/amd64-gcc: +BROKEN_armv6= fails to package Since the compile problem would before any package attempt I've no clue how -r439595 got as far as package if it was using clang to do the build. armv7 still has devel/arm-none-eabi-gcc492 to go. aarch64 is working on: devel/powerpc64-gcc devel/riscv64-gcc devel/sparc64-gcc 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"