How to properly link 16 and 32 bit .o files?

There's quite a bit strange stuff going on with your program, so instead of trying to fix this, I'll go ahead and start from scratch with something correct.

Your bootloader is mostly fine. As you already noticed, you cannot reference symbols from your kernel in your bootloader. The default solution is to just jump to a known location in your kernel (e.g. the beginning) and arrange things for the kernel to have its entry point there. So we change boot.asm and remove EXTERN _start, replacing it with

_start  EQU 0x7e00

To have the kernel reliably be enterable at 0x7e00, there is a trick. In the linker script, we put the following lines into the beginning of the .text section in linker32.ld:

.text : AT(0x7E00)
{
    _start = .;
    BYTE(0xE9);
    LONG(_main - _start - 5);

This makes .text begin with a JMP instruction that jumps to _main, which is exactly what we want.

Next is the issue of random junk being appended to the kernel. This is because you don't discard enough crap. The easiest way is to just discard everything (i.e. *(*)) and explicitly list the sections you want to keep. You need to be careful though; the compiler may decide to put extra junk into weird sections that is needed to keep the kernel working. Alternatively, accept that the compiler does whatever it wants and eat up the larger kernel size. The final linker script linker32.ld is this:

OUTPUT_FORMAT(elf32-i386);
OUTPUT_ARCH(i386);
SECTIONS
{
    . = 0x7E00;

    .text : AT(0x7E00)
    {
        _start = .;
        BYTE(0xE9);
        LONG(_main - _start - 5);
        *(.text);
        *(.text.*);
    }
    
    .data :
    {
        *(.bss);
        *(.bss*);
        *(.data);
        *(.rodata*);
        *(COMMON);
    }  
    /DISCARD/ :
    {
    *(*);
    }
}

You can fix the discarded sections similarly in linker16.ld.

Next is the build script. I'll not discuss this in detail, but you can check the changes I made yourself. The two important ones are (a) removing -relocatable (this is absolutely not what you want) and (b) adding -fno-pic -no-pie so the compiler doesn't get any weird ideas.

all:
    nasm -f elf32 boot.asm
    gcc -m32 -c -g -fno-pic -no-pie -ffreestanding -nostdlib -nostdinc -Wall -Werror -o kernel.o kernel.c
    ld -static -nostdlib -build-id=none -T linker16.ld -o boot.elf boot.o
    ld -static -nostdlib -build-id=none -T linker32.ld -o kernel.elf kernel.o
    objcopy -O binary boot.elf boot.bin
    objcopy -O binary kernel.elf kernel.bin
    cat boot.bin kernel.bin > sys.bin
    qemu-system-i386 sys.bin

qemu:
    qemu-system-i386 sys.bin

It should work like this, assuming the boot loader is correct (I don't have QEMU on this computer).

There really isn't any such thing as a 16-bit ELF executable or object. 16-bit code is contained inside a 32-bit or 64-bit ELF object and the LD linker has support for relocations specific to 16-bit code.

It is possible for you to generate a program like kernel.elf and use the symbols when linking another program together. The LD linker has the option -R for this purpose:

   -R filename
   --just-symbols=filename
       Read symbol names and their addresses from filename, but do not
       relocate it or include it in the output.  This allows your output
       file to refer symbolically to absolute locations of memory defined
       in other programs. You may use this option more than once.

Assuming you assembled kernel.asm and linked to kernel.elf, you can build boot.elf from boot.o by using the symbols from kernel.elf like this:

ld -static -nostdlib -build-id=none -T linker32.ld -o kernel.elf kernel.o
ld -static -nostdlib -build-id=none -T linker16.ld -R kernel.elf -o boot.elf boot.o

In boot.asm you would be able to reference symbols in kernel.elf like _main just by putting extern _main on the assembly file boot.asm

You're supposed to cat the 16 and 32 bit binaries together not the .o files. The idea is the 32 bit binary starts in memory right after the end of the 16 bit binary; so you arrange for the 16 bit binary to know its length and find the 32 bit binary.

One technique is scanning for the start of the 32 bit binary starting from the last byte of the 16 bit data region. The 16 bit trailer probably won't contain the 32 bit header, and this will be reliable on build so you know if the technique works or not the first time you try to boot the result.

NOTE: while this answer isn't wrong; I suspect that fuz will be placing a better answer shortly.