Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Apr 2017 20:40:10 -0700
From:      Mark Millard <markmi@dsl-only.net>
To:        svn-ports-head@freebsd.org, Mark Linimon <linimon@lonesome.com>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>
Cc:        Alexander Kabaev <kabaev@gmail.com>
Subject:   Re: 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
Message-ID:  <1E21DD74-6F0E-4D60-8595-95BFDEC0884B@dsl-only.net>
In-Reply-To: <5EC77319-3775-4333-BD1E-B08359C354E3@dsl-only.net>
References:  <8E45FA57-8D2E-4159-8E02-6A5044000CC2@dsl-only.net> <B15B5A54-B48B-4BBA-BB55-8D24652833AD@dsl-only.net> <27396BB5-21BC-453A-AD14-E711C15D365F@dsl-only.net> <5EC77319-3775-4333-BD1E-B08359C354E3@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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:
>=20
>> On 2017-Apr-28, at 5:24 PM, Mark Millard <markmi at dsl-only.net> =
wrote:
>>=20
>>> On 2017-Apr-28, at 3:27 PM, Mark Millard <markmi at dsl-only.net> =
wrote:
>>>=20
>>>> Just FYI:
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> [Because of this I've been reverting devel/*binutils
>>>> to -r436731 each time I update the revision of
>>>> /usr/ports.]
>>>>=20
>>>> 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:
>>>>=20
>>>> amd64: built amd64-gcc powerpc64-gcc aarch64-gcc
>>>> powerpc64: built powerpc64-gcc
>>>> aarch64: built aarch64-gcc
>>>> (Note: aarch64 is using -mcpu=3Dcortex-a53 explicitly.)
>>>>=20
>>>> Context: head -r317015 in each case.
>>>> (WITH_LLD_IS_LD=3D was used on aarch64.)
>>>> (powerpc64 is system-clang/libc++ based, used
>>>> devel/*binutils)
>>>>=20
>>>> 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.)
>>>>=20
>>>> I also have access to armv7. (In this context
>>>> I normally use -mcpu=3Dcortex-a7 explicitly.)
>>>> So I could try that type of host as well.
>>>>=20
>>>> I do not have access to mips, mips64, riscv, sparc64
>>>> so they could be targets but not hosts in my tests:
>>>> always cross-builds.
>>>>=20
>>>> 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.)
>>>=20
>>> 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 "=3Da" problem for the clang based build:
>>>=20
>>> =
/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38=
6/cpuid.h:223:3: error: invalid output constraint '=3Da' in asm
>>> __cpuid (__ext, __eax, __ebx, __ecx, __edx);
>>> ^
>>> =
/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38=
6/cpuid.h:165:7: note: expanded from macro '__cpuid'
>>>         : "=3Da" (a), "=3Db" (b), "=3Dc" (c), "=3Dd" (d)     \
>>> . . . (other such messages) . . .
>>> In file included from =
/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/c=
ppspec.c/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/co=
nfig/i386/driver-i386.c:554::225: error: invalid output constraint '=3Da' =
in asm
>>> . . .
>>>        : "=3Da" (eax), "=3Dd" (edx)
>>>         ^
>>> . . .
>>>=20
>>> So this system-clang context on powerpc64 is like -r439595
>>> reports for building devel/amd64-gcc on aarch64:
>>>=20
>>> +BROKEN_aarch64=3D		error: invalid output constraint '=3Da' =
in asm
>>>=20
>>> head/devel/amd64-gcc/Makefile only says:
>>>=20
>>> BROKEN_powerpc64=3D	Does not build
>>>=20
>>> but it is like on aarch64 --at least when system-clang
>>> compiler that is in use.
>>>=20
>>> The compiler command lines were:
>>>=20
>>> c++ -std=3Dgnu++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/../inclu=
de =
-I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcp=
p/include -I/usr/local/include  =
-I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde=
cnumber =
-I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde=
cnumber/dpd -I../libdecnumber =
-I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libba=
c
>> 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/i38=
6/driver-i386.c
>>>=20
>>> c++ -std=3Dgnu++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/../inclu=
de =
-I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcp=
p/include -I/usr/local/include  =
-I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde=
cnumber =
-I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde=
cnumber/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/c=
ppspec.c
>>>=20
>>> 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 .
>>=20
>> Based on the aarch64 context specified in the
>> original note (system version, /usr/ports versions,
>> and the like). . .
>>=20
>> The following built fine:
>>=20
>> =3D=3D=3D>>> 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)
>>=20
>> But devel/arm-none-eabi-gcc492 then conflicts with
>> devel/arm-none-eabi-gcc :
>>=20
>> =3D=3D=3D>   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
>>=20
>> So to test devel/arm-none-eabi-gcc492 fully requires that
>> any pre-installed devel/arm-none-eabi-gcc first be
>> deleted/removed.
>>=20
>> 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.
>>=20
>> So the following did not have package problems:
>>=20
>> devel/aarch64-none-elf-gcc-6.3.0
>> devel/arm-none-eabi-gcc
>>=20
>> But that last was given that devel/arm-none-eabi-gcc492
>> had not been installed.
>>=20
>>=20
>> I still have the following to go on aarch64 (cortex-a53):
>>=20
>> devel/powerpc64-gcc
>> devel/riscv64-gcc
>> devel/sparc64-gcc
>> devel/amd64-gcc
>>=20
>> I also have armv7 (cortex-a7) attempting:
>>=20
>> devel/arm-none-eabi-gcc492
>> devel/amd64-gcc
>=20
> The armv7 attempt at devel/amd64-gcc also got
> the "=3Da" problem, such as:
>=20
> =
/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38=
6/driver-i386.c:608:2: error: invalid output constraint '=3Da' in asm
>        __cpuid (0x80000002, name, ebx, ecx, edx);
>        ^
> =
/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38=
6/cpuid.h:165:7: note: expanded from macro '__cpuid'
>           : "=3Da" (a), "=3Db" (b), "=3Dc" (c), "=3Dd" (d)     \
>             ^
>=20
> 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.)
>=20
> Not that this is different from -r439595's
> report, which said for devel/amd64-gcc:
>=20
> +BROKEN_armv6=3D		fails to package
>=20
> 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.
>=20
> armv7 still has devel/arm-none-eabi-gcc492 to go.
>=20
> aarch64 is working on:
>=20
> 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 :

=3D=3D=3D>   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=3D		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.)

=3D=3D=3D
Mark Millard
markmi at dsl-only.net





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1E21DD74-6F0E-4D60-8595-95BFDEC0884B>