Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 4 Aug 2020 14:27:58 -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:   aarch64: unable to use lang/gcc10 to use system libc++, unlike back with lang/gcc9, failure: __aarch64_ldadd8_acq_rel missing
Message-ID:  <E65995FF-2C48-41B3-96B6-93B6C67E7103@yahoo.com>
References:  <E65995FF-2C48-41B3-96B6-93B6C67E7103.ref@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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:

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

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 .



I've just tried the same sort of thing for using lang/gcc10 and
targeting aarch64 and it fails to build:

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

It ended up failing for:

/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

Stop.
make: stopped in /root/acpphint/acpphint_src

(Omitting -Wl,-rpath=3D/usr/local/lib/gcc10 made no difference.)

I did not have such an issue for powerpc64. I've not tried the
other platforms yet.


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?


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

=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?E65995FF-2C48-41B3-96B6-93B6C67E7103>