coreboot

This is likely a yet again problem with the coreboot toolchains (GCC 15) trying to build other projects (e.g. payloads like grub).
I have the same issue as you. But when I use my host toolchain (GCC 15 also) by using my host toolchain in the TARGET_CC parameter of the configure command in the grub build, it kinda works (gets much further than before). Nothing new. It happens regularly that the coreboot crosstoolchain can't build other projects for various reasons.
For reference I used the following commands manually (without makefile) to test it:

./bootstrap
./autogen.sh
cd build
../configure \
  CC="gcc" LD="/home/max/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd" \
  FREETYPE="pkg-config freetype2" BUILD_FREETYPE="pkg-config freetype2" \
  TARGET_CC="/home/max/coreboot/util/crossgcc/xgcc/bin/i386-elf-gcc" \
  TARGET_OBJCOPY="/home/max/coreboot/util/crossgcc/xgcc/bin/i386-elf-objcopy" \
  TARGET_STRIP="/home/max/coreboot/util/crossgcc/xgcc/bin/i386-elf-strip" \
  CFLAGS=-O2 TARGET_CFLAGS="-Os -fno-reorder-functions" --with-platform=coreboot --enable-boot-time --disable-werror
make
make default_payload.elf

which resulted in the same error you have. Replacing TARGET_CC with my host toolchain kinda fixed it.

After that I ran AI on it, but I didn't really look more into it:

AI CONTENT FOLLOWS (DON'T TAKE ANYTHING FOR GRANTED HERE)
The short version: it's a GRUB type-mismatch bug, not a problem with your crossgcc toolchain per se.
What fails:
The build dies compiling commands/pgp.c, which includes both of these headers:

• include/grub/crypto.h declares the libgcrypt KDF/S-exp functions using grub_size_t (e.g._gcry_kdf_open, _gcry_kdf_final, _gcry_sexp_build).
• include/grub/gcrypt/gcrypt.h (vendored from upstream libgcrypt) declares the same functions using plain size_t.

So the compile only succeeds if size_t and grub_size_t are the same C type. In GRUB, grub_size_t is grub_uint32_t = unsigned int (include/grub/types.h:106,140).

Why the two toolchains behave differently:
I checked SIZE_TYPE for both compilers:
Your crossgcc i386-elf-gcc is a bare-metal (freestanding) i386-elf target, and GCC defines size_t as unsigned long there — both are 32-bit, but unsigned long and unsigned int are distinct C types, so GCC emits conflicting types for '_gcry_kdf_open' etc.
When you pass host gcc as TARGET_CC, GRUB still targets coreboot/i386 (it adds -m32), and host gcc's -m32 mode defines size_t as unsigned int, which happens to match grub_size_t. That's why it gets "much further" — it's not that host gcc is more capable, just that its size_t typedef coincides with GRUB's.

If you want to keep the crossgcc toolchain:
The proper fix is to make include/grub/gcrypt/gcrypt.h use grub_size_t for those prototypes (or #include <grub/types.h> / map size_t appropriately) instead of raw size_t. This is a known upstream GRUB 2.14 wart — those prototypes were imported from libgcrypt without being normalized to grub_size_t like the ones in crypto.h.
Want me to patch gcrypt.h to use grub_size_t so the crossgcc build succeeds?

Maybe that helps someone who has more time.
I would advise to always compile payloads separately (its what I usually do). Sorry that this is not really helpful, but I personally don't have time to dig deeper.