For context, I have been working on a game engine for a while now. The engine requires several libraries to function (Wayland, XKB, Vulkan, etc.). Because the added complexity of shared libraries leaves a bad taste in my mouth, the engine is archived into a static library via the ar utility, and I use Makefile to build the project.
I was trying to figure out an elegant way to link engine dependencies in games, and came across the ar -l option, which advertises to keep link-time dependencies alongside the library. However, when I specify said dependencies in the format they request (all in a string, in the format the linker expects), nothing is actually linked in the game executables, they still report the same missing function definitions.
Is this option unimplemented? Have I misread something?
What is the Purpose of the AR "-l" Option?
The behavior depends on what version of ar you're looking at.
POSIX, does not document such an option at all. Some implementations do not support it.
Some Unixes with a strong SysV lineage, such as AIX and IRIX, document it has having an effect on where temporary files are stored.
That SysV behavior is probably what inspired old versions of GNU ar to implement the l option as a do-nothing option for compatibility.
Your description sounds more like recent versions of GNU ar, which document l to have this effect:
Specify dependencies of this library. The dependencies must immediately follow this option character, must use the same syntax as the linker command line, and must be specified within a single argument. I.e., if multiple items are needed, they must be quoted to form a single command line argument. For example
l "-L/usr/local/lib -lmydep1 -lmydep2"
and that may be what inspired FreeBSD to implement -l as a do-nothing option for compatibility with GNU ar.
Even if you're using a recent version of GNU ar, it's not clear what it actually does with whatever data you provide via that option. Probably it stores that somewhere in the archive, but even that is uncertain. If it does store it in the archive then it's unclear where, as the format has no specific provision for it.
The purpose of this option is a different and more speculative question. The format expected for the data suggests that it might, under some circumstances, be used by the linker, but if so then probably only GNU ld and not any other. And that might well not be implemented in ld yet, and if ever it were then I would expect that to require an opt-in, as it could change the behavior of some builds. I don't find any such opt-in documented for ld, nor any reference at all to embedded dependency information.
Is this option unimplemented? Have I misread something?
At minimum, it is somewhat new, and very GNU-specific. Even if it does store the provided data somewhere in the archive, it is unclear whether any other tools do anything with that data. I guess you were hoping that the linker would automatically read that data and use it as additional link options, but if that's not working for you then that's probably end of story, at least for now. There does not appear to be any documented way to make the linker take notice.
I was trying to figure out an elegant way to link engine dependencies in games
Well there's an area where you get something for the added complexity of shared libraries that seems so distasteful to you. Shared libraries do carry information -- in a standard and well supported format -- about their dependencies.
Personally, I don't see or even really comprehend your particular objection, but if you insist on building your engine as a static library, and you want to provide a way for you or other developers to get at dependency information at build time, then you should consider an established, more widely recognized mechanism such as pkgconf.