svn commit: r439595 - in head/devel: aarch64-gcc aarch64-none-elf-gcc amd64-gcc arm-none-eabi-gcc arm-none-eabi-gcc492 mips-gcc mips64-gcc powerpc64-gcc riscv64-gcc sparc64-gcc
Mark Millard
markmi at dsl-only.net
Sat Apr 29 08:19:21 UTC 2017
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/../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. )
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
More information about the freebsd-toolchain
mailing list