Add GCC 15.1 COBOL (libgcobol) musl compatibility patch

[kwinsch]

I was bored today and tried some COBOL that was recently merged and released in GCC 15.1. After non successful static linking using glibc, I just tried to compile it with my usual goto musl-cross-make, that succeeded using the patch attached.

So if someone else is in search on how to fully statically link COBOL programs, the patch may help. The patch was not yet submitted upstream.

Some config hints:

# Configuration for GCC 15.1 with COBOL support

TARGET = x86_64-linux-musl

# Use GCC 15.1.0 (includes COBOL frontend)
GCC_VER = 15.1.0

# Enable C, C++, and COBOL languages
GCC_CONFIG += --enable-languages=c,c++,cobol

Simple Hello World seems to be around 672 KB after stripping.

---

This patch adds musl libc support for GCC 15.1's new COBOL frontend by making the execinfo.h include conditional on HAVE_EXECINFO_H.

Background:

• GCC 15.1 introduced native COBOL support (gcobol compiler)
• libgcobol unconditionally included <execinfo.h>, a glibc-specific header
• musl libc does not provide execinfo.h (backtrace functions)
• The header was included but never actually used in the code

This patch:

• Guards the execinfo.h include with #ifdef HAVE_EXECINFO_H
• Allows libgcobol to build successfully with musl
• No functional changes (execinfo.h was not used)
• Enables fully static COBOL binaries via musl

Tested with:

• GCC 15.1.0
• musl 1.2.5
• Target: x86_64-linux-musl
• Successfully compiles and runs COBOL programs

[GitMensch]

Just out of interest: What is the issue with static linking via gcobol+glibc? Is this different from gcc(cc1)+glibc?
Note: I've sent the patch and the question "can it be removed altogether" to one of the gcobol maintainers.

[kwinsch]

I haven't deep-dived into the exact failure modes lately (and things may have improved a bit with modern glibc), but the classic problem is still there: glibc was never designed with fully-static linking in mind and its maintainers have historically treated it as unsupported. (Supported only static linking, except glibc itself).

A lot of libc functionality (NSS, iconv, locales, etc.) is implemented via dlopen() plugins, so in a -static binary those dlopen() calls may fail and a bunch of stuff silently breaks or degrades (DNS resolution, user lookups, etc.).
It's exactly the same problem as with any other GCC language/runtime (C, C++, Fortran, COBOL…). The COBOL frontend doesn't do anything special.

musl just works because it was built from day one to support proper static linking without any runtime surprises.

In short, since musl was stable, I just did never bother to really test if newer versions of glibc may have improved for fully static linked executables.

Thanks for sending the patch upstream.

[GitMensch]

Thanks for the explanation!

But now I'm curious... (sorry for the topic-drift)
Can you inspect someday about how to statically link with GnuCOBOL's cobc?

cobc calls the compiler+linker and passes any -l and -L options; you can manually add as much options to compiler/linker as you want with the -A and -Qoptions; I _guess_ the runtime itself needs to be statically linked [including libc + GMP, if not disabled then BDB - I'd suggest to useconfigure --without-db` to turn it of - and optional dependencies like curses and json-c and libxml2 come on top] which could mean the need to also link all of those in the executable again... but I only statically link "application", not system libraries so I don't know.