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 02:15:09 UTC 2017
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/../libbac
> 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
More information about the freebsd-toolchain
mailing list