runnning after linking without -Wl,-rpath=/usr/local/lib/gcc9 : ld-elf.so.1: . . . : Undefined symbol "__floatunditf at GCC_4.2.0" (possibly arm specific)

[Mark Millard]

On 2019-Sep-6, at 23:29, Mark Millard <marklmi at yahoo.com> wrote:

> When I built a fairly simple C++17 program (not FreeBSD specific) 
> (targeting aarch64) with g++9 and then tried to run it, running
> reported (I omit a very long file path/name that I was using):
> 
> ld-elf.so.1: . . . : Undefined symbol "__floatunditf at GCC_4.2.0"
> 
> # ldd . . .
> . . .:
> 	libstdc++.so.6 => /usr/local/lib/gcc9/libstdc++.so.6 (0x404dc000)
> 	libm.so.5 => /lib/libm.so.5 (0x406d4000)
> 	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40745000)
> 	libthr.so.3 => /lib/libthr.so.3 (0x40786000)
> 	libc.so.7 => /lib/libc.so.7 (0x407e2000)
> 
> Using -Wl,-rpath=/usr/local/lib/gcc9 in the link avoided the
> problem and let the program run (by changing which library
> is used, for at least one library).
> 
> I've not checked if this is aarch64 specific or FreeBSD vintage
> specific or g++ vintage specific. (The context is head -r350364 .)

powerpc64 did not require the -Wl,-rpath=/usr/local/lib/gcc9

So some architectures do not have the problem.

> (The program and its source are not ready for any distribution.)

When attempting to use g++9 with the system libc++ instead of
libstdc++ on aarch64 I got it to work by making it use:

# ldd . . .
. . .:
	libc++.so.1 => /usr/lib/libc++.so.1 (0x404e2000)
	libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x405d5000)
	libthr.so.3 => /lib/libthr.so.3 (0x4061a000)
	libm.so.5 => /lib/libm.so.5 (0x40676000)
	libc.so.7 => /lib/libc.so.7 (0x406e7000)
	libgcc_s.so.1 => /usr/local/lib/gcc9/libgcc_s.so.1 (0x40abe000)

In other words: make it avoid use of:

	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40abe000)

in order to pick up a definition of __floatunditf at GCC_4.2.0 .

But the odd mix is probably not a generally good idea.

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