aarch64: unable to use lang/gcc10 to use system libc++, unlike back with lang/gcc9, failure: __aarch64_ldadd8_acq_rel missing

[Mark Millard]

On 2020-Aug-4, at 14:27, Mark Millard <marklmi at yahoo.com> wrote:
> 
> 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+=           -Wno-psabi -nostdinc -nostdinc++ -I/usr/include/c++/v1 -I/usr/include
> . . .
> LDCXX=          -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s \
>                -Wl,-rpath=/usr/local/lib/gcc9
> . . .
> # Note: FreeBSD's libgcc_s were missing at least a floating point routine.
> #       The -Wl,-rpath=/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=... was required. Targeting armv7 did require use of
> -Wl,-rpath=/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+=           -Wno-psabi -nostdinc -nostdinc++ -I/usr/include/c++/v1 -I/usr/include
> . . .
> LDCXX=          -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s \
>                -Wl,-rpath=/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=/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.)

I just tried lang/gcc9 ( -r543890 ports ) on a head -r363590
aarch64 based system, without -Wl,-rpath=/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 at GCC_4.2.0"

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


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)