Of course, right after I send the email ... here's another piece of evidence, which I think is consistent with my interpretation below.

If I simply add the following function to one of my C files:

void you_gotta_be_kidding_me(int arg)
{
    jmp_buf buf1;
    sigjmp_buf buf2;

    setjmp(buf1);
    sigsetjmp(buf2, arg);
}

... the linker error goes away. My hypothesis is/was that code like this would encourage the linker to locate the two libc functions closer together, so that the relocation is no longer truncated. So, it appears that I at least have a workaround.

Peter

On Wed, 2023-09-06 at 20:46 -0400, Peter Williams wrote:
Hello,

I'm experiencing a software issue that I think maybe, might, possibly, indicate a musl bug. I'm not at all familiar with the issues involved, but it looks like emailing this list might be my best bet for testing that hypothesis, so that's what I'm doing. Please CC me on any replies as I'm not subscribed, and accept my apologies if I'm way off base here.

The short answer is that I'm trying to link a large (~100 MB) static executable for aarch64 and getting this error out of the binutils linker:

  /home/rust/sysroot-aarch64/usr/lib/libc.a(sigsetjmp.lo): in function `sigsetjmp':
  /home/buildozer/aports/main/musl/src/v1.2.3/src/signal/aarch64/sigsetjmp.s:7:(.text+0x0):
    relocation truncated to fit: R_AARCH64_CONDBR19 against symbol `setjmp'
    defined in .text section in /home/rust/sysroot-aarch64/usr/lib/libc.a(setjmp.lo)

If I'm understanding correctly, the complaint is that a branch in sigsetjmp that invokes setjmp is too far away from the definition of setjmp. My very handwavey idea is that maybe for some reason my program is causing the linker to want to locate setjmp() and sigsetjmp() really far away from each other. If that's right, perhaps it would be possible to modify the assembler code to be able to handle such a situation?

My build environment is extremely gnarly — I am running my build tools inside a cross-compiling Alpine Linux chroot that in turn runs inside an Ubuntu Docker container. (You don't want to know.) I can provide more details if needed, as well as a script that leads up to the error on my system, if you have CPU time to burn on the Docker container build. But since the error seems to be localized within my aarch64 "libc.a", I'm hopeful that maybe this funky environment doesn't actually affect the core situation here. As you might see in the output above, I'm using musl 1.2.3.

Thanks for any insight,

Peter