fix(tur/gcc-{14,15}): apply --with-ld=$TERMUX_PREFIX/bin/ld.bfd

[robertkirkman]

• Fixes [Bug]: 32-bit ARM gcc-15 in TUR is not compatible with lld providing ld and termux-pacman has outdated command-not-found termux/termux-packages#29175

• Necessary after rmpkg(main/binutils-is-llvm): make LLVM binutils default in Termux termux/termux-packages#28586

[robertkirkman]

I was worried that this would be necessary and anticipated that in this comment,

• rmpkg(main/binutils-is-llvm): make LLVM binutils default in Termux termux/termux-packages#28586 (comment)

but after considering the options and tradeoffs, I decided that it was more important to prioritize the packages in the main repository than to prioritize the packages in TUR, so the linked issue occurred, I am very sorry about that if that's unacceptable,

for some reason, the issue only seems to affect the GCC packages on 32-bit ARM and not any other architectures, but this will apply --with-ld=$TERMUX_PREFIX/bin/ld.bfd to all architectures since these GCC packages are marked as depending on binutils, which contains ld.bfd, so it is a good idea for it to be applied to all architectures.

Unfortunately, I'm not able to recompile gcc-13 because of an error,

/home/builder/.termux-build/_cache/android-r29-api-24-arm-linux-androideabi-gcc-13.4.0-r0-v2-sysroot-r0/include/c++/13.4.0/__type_traits/is_reference.h:22:85: error: there are no arguments to '__is_reference' that depend on a template parameter, so a declaration of '__is_reference' must be available [-fpermissive]
   22 | struct _LIBCPP_TEMPLATE_VIS _LIBCPP_NO_SPECIALIZATIONS is_reference : _BoolConstant<__is_reference(_Tp)> {};
      |                                                                                     ^~~~~~~~~~~~~~
/home/builder/.termux-build/_cache/android-r29-api-24-arm-linux-androideabi-gcc-13.4.0-r0-v2-sysroot-r0/include/c++/13.4.0/__type_traits/is_reference.h:22:85: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)

is it important to continue to maintain the older version GCC packages?

[licy183]

GCC-13 hasn't reached EOL yet, so I think it still needs maintenance. I might take a look at it this evening. If I don't have time tonight, I'll take a look at the weekend.

[robertkirkman]

I will apply this now to fix gcc-14 and gcc-15, then continue trying to fix gcc-13 and older