Re: static linking vs. __attribute__((constructor)) et al

On Thu, 27 Feb 2025, Greg A. Woods wrote:

> /Volumes/work/woods/g-NetBSD-src/external/mpl/bind/lib/libisc/../../dist/lib/isc/mem.c:475:mem_create(): fatal error: pthread_mutex_init(): Invalid argument (22)
> Abort (core dumped)
>
> The problem facing successful static-linking is that the objects
> containing those constructor functions (i.e. from libraries)
> often/usually won't get linked into the final binary, and so of course
> they can never be run, usually leaving key data structures
> uninitialised.
>

Yes (can effect dynamically-linked binaries too, for the same reason).

> I think the right solution is to ask the linker to pull in any and all
> objects from any and all mentioned libraries if they have a .ctors
> section.  I don't see any obvious way to do this, but my understanding
> of GNU ld linker scripts is very limited.
>

I'm pretty sure that linker scripts won't help here, because by the time the
linker scripts are run to assemble the binary, the symbol resolution phase has
already happened and has discarded unreferenced objects.

You'll have to write a linker-plugin to do what you want. (Writing any other
type of script to trawl through an `objdump -r' output, say, is likely to be
very fragile.)

> Does anyone have any ideas of how to achieve successful static linking
> of libraries with constructors without -whole-archive and without
> using explicit references to all constructors?
>

What's usually done is to use either `-u sym' or `--require-defined=sym'
on any of the syms (usually the constructor) in the object you want to pull in.

HTH,

-RVP