On 2017-Apr-28, at 10:59 PM, Mark Millard <markmi at dsl-only.net> wrote:
> 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/../li b > 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. ) As for aarch64 building/installing devel/mips-gcc and devel/mips64-gcc in my context: ===>>> The following actions were performed: Installation of devel/mips-binutils (mips-binutils-2.27_5,1) Installation of devel/mips-gcc (mips-gcc-6.3.0) Installation of devel/mips64-binutils (mips64-binutils-2.27_5,1) Installation of devel/mips64-gcc (mips64-gcc-6.3.0) So no problem. This is different from -r439595 reporting for both: +BROKEN_aarch64= fails to package That completes a round of testing hosts: aarch64 (using -mcpu=cortex-a53 ) armv6 (on a armv7 using -mcpu=cortex-a7 ) powerpc64 (even this using system-clang) relative to the -r439595 reports but based on using the patch from D10537, using 2.27 of devel/*binutils and the like (-r436731 ), /usr/ports at -r439263 otherwise, all using system-clang to do the builds (head -r317015 ). Hopefully comparison/contrast will provide some useful information. === 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"