On 2017-Apr-28, at 8:40 PM, Mark Millard <markmi at dsl-only.net> wrote:
> 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/../lib b > 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.) [I seem to have forgotten to list devel/mips-gcc and devel/mips64-gcc and so will have to start those builds on aarch64.] The aarch64 attempt at building devel/amd64-gcc also got the "=a" problem, for example: /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) \ ^ This did match the -r439595 report for the combination. But for every non-amd64 host that I tried that used clang to build devel/amd64-gcc the same problem happened. (I did no testing of gcc 4.2.1 or other compilers than system-clang under head -r317015.) Other than the devel/arm-none-eabi-gcc492 conflict with devel/arm-none-eabi-gcc everything else built on aarch64 just fine: ===>>> The following actions were performed: Installation of devel/powerpc64-binutils (powerpc64-binutils-2.27_5,1) Installation of devel/powerpc64-gcc (powerpc64-gcc-6.3.0) Installation of devel/riscv64-binutils (riscv64-binutils-2.27.51.20161101) Installation of devel/riscv64-gcc (riscv64-gcc-6.1.0) Installation of devel/sparc64-binutils (sparc64-binutils-2.27_5,1) Installation of devel/sparc64-gcc (sparc64-gcc-6.3.0) Installation of devel/amd64-binutils (amd64-binutils-2.27_5,1) where before I'd reported: ===>>> 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) and I'd tested building devel/aarch64-gcc on aarch64 as part of testing the patch in D10537 earlier in the day. Note: This is different than the -r439595 reports for aarch64 hosts: devel/aarch64-gcc: +BROKEN_aarch64= configure: error: cannot compute suffix of object files: cannot compile devel/aarch64-none-elf-gcc: devel/arm-none-eabi-gcc: devel/powerpc64-gcc: devel/riscv64-gcc: devel/sparc64-gcc: +BROKEN_aarch64= fails to package (Some of those might be from some prior install that conflicts, like I saw for devel/arm-none-eabi-gcc492? Of course I was also using -r436731 of devel/*binutils (2.27) because of some known 2.28 build failures associated with 2.28. ) === 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"