The combination of -Wl,--export-dynamic and -static is used by some Autoconf tests ("checking whether a statically linked program can dlopen itself"). This consistently drops a core on 12-stable (tested at r344237) but apparently not on 11-stable. Tested on amd64 and armv7.
dlopen is not actually implicated in the issue: it can be reproduced with only this:
cc -g -Wl,--export-dynamic -static testprog.c
segmentation fault (core dumped) ./a.out
The problem seems to be that the a.out is actually dynamic in spite of the -static option, but it still has libc.a statically linked into it. With ld.bfd, the a.out comes out as static and there is no coredump.
I doubt this is breaking any real code, but it generates a lot of worrying logfile entries when building ports.
Kicking it over to -toolchain@
We also ran into this problem in CheriBSD. The binary is actually static (but file will report it as dynamically linked). However, it has a PT_DYNAMIC header and the symbol _DYNAMIC does not resolve to zero. This causes these crashes because there are various checks in libc, csu code, etc. that assume that `if (&_DYNAMIC == NULL)` is true the binary is statically linked and otherwise it assumes we are running a dynamic binary.
For our CHERI compilers I just modified ld.lld to not emit _DYNAMIC and the PT_DYNAMIC header. I also attempted to upstream this fix but haven't got around to committing it since I'm not 100% sure what the correct behaviour is.
See also https://reviews.llvm.org/D42748
Replied in https://reviews.llvm.org/D42748#1510087 :)
moving away from &_DYNAMIC will be a more reliable approach.
To check if an executable is dynamically linked, inspecting PT_INTERP is a better choice.
IMO this needs to be addressed in lld. Discussion is happening in LLVM review D42748.
(In reply to Ed Maste from comment #4)
Commented at https://reviews.llvm.org/D42748#1637598
I think libc should probably be changed. That will also benefit future static PIE work.