Date: Mon, 22 Aug 2022 15:05:46 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, "dim@freebsd.org" <dim@FreeBSD.org> Cc: freebsd-arm <freebsd-arm@freebsd.org>, dmenelkir@gmail.com Subject: Re: Reduced reproduction of games/libretro-beetle_psx 's armv7 build failure Message-ID: <3EEFCF79-9AEA-422A-A3F7-D582A673FF8C@yahoo.com> In-Reply-To: <3B0A68EC-438D-48B0-8B6D-BC1BCE59ED73@yahoo.com> References: <3B0A68EC-438D-48B0-8B6D-BC1BCE59ED73@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Aug-22, at 11:30, Mark Millard <marklmi@yahoo.com> wrote: > games/libretro-beetle_psx built for armv7 uses its jit_arm*.c > code. The below is a simplification of the context for the > later shown build failure log file from the FreeBSD package > build servers: >=20 > # more libretro-beetle_psx_build_failure_reduction.c=20 > extern float __addsf3(float, float); > extern double __adddf3(double, double); Investigative activity after an off-list message lead to me to discover that the above 2 are not from the likes of: Run-time ABI for the Arm=C2=AE Architecture but are instead from the likes of: = https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html#Sof= t-float-library-routines associated with what the gcc folks sometimes have in libgcc.a or libgcc_s.so.1 . (The subset varies by architecture from what I've seen.) > int main() > { > (void)__addsf3(0, 0); > (void)__adddf3(0, 0); > } >=20 > # cc libretro-beetle_psx_build_failure_reduction.c > ld: error: undefined symbol: __addsf3 >>>> referenced by libretro-beetle_psx_build_failure_reduction.c >>>> = /tmp/libretro-beetle_psx_build_failure_reduction-e3ff6d.o:(main) >=20 > ld: error: undefined symbol: __adddf3 >>>> referenced by libretro-beetle_psx_build_failure_reduction.c >>>> = /tmp/libretro-beetle_psx_build_failure_reduction-e3ff6d.o:(main) >>>> did you mean: __adddi3 >>>> defined in: /lib/libc.so.7 > cc: error: linker command failed with exit code 1 (use -v to see = invocation) The same goes for trying allowing the use of libgcc_s.so.1 to supply definitions: # cc -lgcc_s libretro-beetle_psx_build_failure_reduction.c ld: error: undefined symbol: __addsf3 >>> referenced by libretro-beetle_psx_build_failure_reduction.c >>> = /tmp/libretro-beetle_psx_build_failure_reduction-fefae9.o:(main) ld: error: undefined symbol: __adddf3 >>> referenced by libretro-beetle_psx_build_failure_reduction.c >>> = /tmp/libretro-beetle_psx_build_failure_reduction-fefae9.o:(main) >>> did you mean: __adddi3 >>> defined in: /lib/libc.so.7 cc: error: linker command failed with exit code 1 (use -v to see = invocation) > An recent example of the build failure on the FreeBSD package > builder servers is: >=20 > = http://ampere2.nyi.freebsd.org/data/main-armv7-default/p85ef7d020401_s0fd8= d3589/logs/errors/libretro-beetle_psx-0.20220211_1.log >=20 > There may be other examples than __addsf3 and __adddf3 (in > other software?). It seems there must not be a (complete) > test for the coverage of such things. >=20 > That same reduced-problem source (by content) builds for > aarch64 and runs fine on aarch64. >=20 > There are more issues with missing math routines vs. the lang/gcc* > code generation --on aarch64 as well. But the above sticks to > system-clang's toolchain as a context. It seems that, despite no direct use of lang/gcc* , I'd wondered into an example of use of gcc* related definitions, where FreeBSD does not have the 2 math routines covered for armv7 (but does for aarch64). > Note: I do not normally build games/libretro-beetle_psx and never > use it. I got here from looking into a somewhat analogous failure > and looking to find an official activity that was similar that I > could reference. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EEFCF79-9AEA-422A-A3F7-D582A673FF8C>