🔗 Turns out gcc has imperative argument handling

The Linux program with most contrived argument handling logic ever has got to be gcc.

Everything in it has a reason, of course, but the end result is that you get a weird mix where the order matters for some args and not for others PLUS there are imperative arguments:

Say you want to link a static library into your program (I’m going to use […] to skip other flags)

gcc -o myprogram [...] myprogram.c libmylibrary.a [...]

This works, but now you want to add plugins to your program. So you add some runtime dynamic linking logic and add -ldl.

Oops, you realize your plugins can’t find some symbols from the static library, only those already used by the main program. The compiler threw away everything from libmylibrary.a that was “unused”.

-Wl,–whole-archive to the rescue!

Wait, what’s that? Two flags joined by a comma?

Turns out gcc is a main driver command which launches other programs, and passes arguments along to them. -Wl,–something means that it will pass the flag –something to the linker. You can add after -Wl, anything that is understood by ld, the GNU Linker.)

But you have other libraries you’re linking as well, and now you start getting duplicated symbol errors when compiling, because it is linking too much stuff! The solution? Wait for it…

gcc [...stuff...] -Wl,--whole-archive libfoo.a -Wl,--no-whole-archive [...other libs...]

The arguments in gcc when dealing with linker options are not only positional, they are imperative!

And I mean that in a quite literal sense. They interpreted like a sequence with side-effects: you set a flag, the next libraries is affected by it, you unset the flag, the following libraries aren’t affected anymore.

I thought find was a strong contender for Unix command with the weirdest argument handling, but I guess gcc takes the cake. 🍰