On 2017-Apr-28, at 7:15 PM, Mark Millard <markmi at dsl-only.net> wrote:
> 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/../libb ac >> 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 The armv7 attempt at devel/arm-none-eabi-gcc492 also got the conflict 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 Note that this is different than the -r439595 report: +BROKEN_armv6= error: no member named 'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'? I've no clue what caused the "fancy_abort" problem reported in -r439595 . Only one of: devel/arm-none-eabi-gcc vs. devel/arm-none-eabi-gcc492 can be installed at a time and to install one required removal/deletion of the other first (if it already exists). Other than the conflict everything looks to have worked up to trying to actually install. I expect aarch64's attempt at devel/aarch64-gcc to do the same sort of thing. aarch64 is still working on: devel/powerpc64-gcc devel/riscv64-gcc devel/sparc64-gcc devel/amd64-gcc (It has made it to devel/sparc64 , having installed devel/powerpc64-gcc and devel/riscv64-gcc . No package failures but I'm using D10537's patch and I'm using head -r317015 and other details which are likely different from what -r439595 was based on.) === 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"
