Date: Wed, 5 Aug 2020 16:45:46 -0700 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: aarch64: unable to use lang/gcc10 to use system libc++ . . . [ unless I use -mno-outline-atomics for gcc10's 10.1 and later] Message-ID: <1E88269B-C277-4543-BDB5-19CE71F5B93B@yahoo.com> In-Reply-To: <94FBD6B8-87E7-45E9-84F7-3F17D42F4BED@yahoo.com> References: <E65995FF-2C48-41B3-96B6-93B6C67E7103@yahoo.com> <94FBD6B8-87E7-45E9-84F7-3F17D42F4BED@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Aug-4, at 16:52, Mark Millard <marklmi at yahoo.com> wrote:
> On 2020-Aug-4, at 14:27, Mark Millard <marklmi at yahoo.com> wrote:
>>=20
>> Historically I've been able to use lang/gcc9 to build personal
>> aarch64 c++17 applications that used head's libc++ and the
>> like (other than some floating point support code for aarch64).
>> The redirection of g++9 to system libraries and such looks
>> like:
>>=20
>> . . .
>> CXX+=3D -Wno-psabi -nostdinc -nostdinc++ =
-I/usr/include/c++/v1 -I/usr/include
>> . . .
>> LDCXX=3D -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s =
\
>> -Wl,-rpath=3D/usr/local/lib/gcc9
>> . . .
>> # Note: FreeBSD's libgcc_s were missing at least a floating point =
routine.
>> # The -Wl,-rpath=3D/usr/local/lib/gcc9 causes use of gcc9's =
libgcc_s .
>> # So far I've only had the issue for targeting aarch64 and =
armv7.
>> . . .
>>=20
>> I do not know if there is an intention to allow such things vs. if
>> I was just lucky that it worked at the time. Historically I've done
>> the same on powerpc64, 32-bit powerpc, and amd64 as well. On those no
>> -Wl,-rpath=3D... was required. Targeting armv7 did require use of
>> -Wl,-rpath=3D/usr/local/lib/gcc9 .
>>=20
>>=20
>>=20
>> I've just tried the same sort of thing for using lang/gcc10 and
>> targeting aarch64 and it fails to build:
>>=20
>> CXX+=3D -Wno-psabi -nostdinc -nostdinc++ =
-I/usr/include/c++/v1 -I/usr/include
>> . . .
>> LDCXX=3D -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s =
\
>> -Wl,-rpath=3D/usr/local/lib/gcc10
>>=20
>> It ended up failing for:
>>=20
>> /usr/local/bin/ld: ../objs/cpp_clockinfo-g++_10_O3-libc++.o: in =
function `long =
std::__1::__libcpp_atomic_refcount_decrement<long>(long&)':
>> /usr/include/c++/v1/memory:3386: undefined reference to =
`__aarch64_ldadd8_acq_rel'
>> /usr/local/bin/ld: ../objs/cpp_clockinfo-g++_10_O3-libc++.o: in =
function `long =
std::__1::__libcpp_atomic_refcount_increment<long>(long&)':
>> /usr/include/c++/v1/memory:3375: undefined reference to =
`__aarch64_ldadd8_relax'
>> /usr/local/bin/ld: ../objs/cpp_clockinfo-g++_10_O3-libc++.o: in =
function `long =
std::__1::__libcpp_atomic_refcount_decrement<long>(long&)':
>> /usr/include/c++/v1/memory:3386: undefined reference to =
`__aarch64_ldadd8_acq_rel'
>> /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined =
reference to `__aarch64_ldadd8_acq_rel'
>> /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined =
reference to `__aarch64_ldadd8_acq_rel'
>> /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined =
reference to `__aarch64_ldadd8_acq_rel'
>> /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined =
reference to `__aarch64_ldadd8_acq_rel'
>> /usr/local/bin/ld: =
../objs/cpp_clockinfo-g++_10_O3-libc++.o:/usr/include/c++/v1/memory:3386: =
more undefined references to `__aarch64_ldadd8_acq_rel' follow
>> collect2: error: ld returned 1 exit status
>> *** Error code 1
>>=20
>> Stop.
>> make: stopped in /root/acpphint/acpphint_src
>>=20
>> (Omitting -Wl,-rpath=3D/usr/local/lib/gcc10 made no difference.)
>>=20
>> I did not have such an issue for powerpc64. I've not tried the
>> other platforms yet.
>>=20
>>=20
>> Anyone know if I'm out in "if it hurts, then do not do that"
>> land? Or is this something that should be possible but is
>> currently broken?
>>=20
>>=20
>> Note: The C++ source in question tries to be pure C++17 compliant
>> code for normal builds. (And I was doing a normal build: no FreeBSD
>> specific code or the like enabled.)
>=20
> I just tried lang/gcc9 ( -r543890 ports ) on a head -r363590
> aarch64 based system, without -Wl,-rpath=3D/usr/local/lib/gcc9
> used, and it still builds but at run-time programs get the
> likes of:
>=20
> ld-elf.so.1: =
/root/acpphint/acpphint_kernelsurveyors_main-RPi4B-4096MiB-threads_4-LP64-=
FreeBSD_13_r363590M_64bit-g++_9_O3-libc++: Undefined symbol =
"__floatunditf@GCC_4.2.0"
>=20
> So that has not changed. This is a very different issue than
> what attempting to use lang/gcc10 gets.
>=20
I finally figured out what is going on as of
gcc10.1 and later for aarch64: -moutline-atomics
is now the default in gcc10.1 and later for
aarch64 but FreeBSD is not set up for such as far
as I can tell. (Outlined atomics dynamically
detect later-added instructions being available
and use them instead of the original code sequences
that are required on the older aarch64 hardware.
On the older hardware they do things the old way.)
To get the older style of code generation that
avoids needing to have an implementation of the
outlined atomics, I've added use of
-mno-outline-atomics for aarch64. For example,
for avoiding use of gcc's libraries for the most
part:
CXX+=3D -Wno-psabi -nostdinc -nostdinc++ -I/usr/include/c++/v1 =
-I/usr/include
OPT=3D -O3 -mcpu=3Dcortex-a53 -mno-outline-atomics
. . .
LDCXX=3D -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s \
-Wl,-rpath=3D/usr/local/lib/gcc10
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1E88269B-C277-4543-BDB5-19CE71F5B93B>