Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 4 Aug 2020 16:52:42 -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++, unlike back with lang/gcc9, failure: __aarch64_ldadd8_acq_rel missing
Message-ID:  <94FBD6B8-87E7-45E9-84F7-3F17D42F4BED@yahoo.com>
In-Reply-To: <E65995FF-2C48-41B3-96B6-93B6C67E7103@yahoo.com>
References:  <E65995FF-2C48-41B3-96B6-93B6C67E7103@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help


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.)

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:

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"

So that has not changed. This is a very different issue than
what attempting to use lang/gcc10 gets.


=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?94FBD6B8-87E7-45E9-84F7-3F17D42F4BED>