So it turns out instead of learning a language like Erlang, Smalltalk or Lisp, I've ended up learning much more about that old clunker of a language. C.
Not just C really. I already had a passing understanding of C. What I've been learning about this week is the autotools toolchain, gcc, linkers and related kit.
I had a weird problem. This problem only occured on OSX, not on Debian, and everyone I talked to said something along the lines of "It should just work".
Here's a real brief description of the problem:
There are three object files. A, B and C. A contains symbol X. B contains symbol Y, and refers to symbol X. C refers to symbol Y.
gcc A.o B.o C.owill link these together correctly.
A and B are in an 'ar' archive
libD.a, created using
ar cru libfoo.a A.o B.o; ranlib libD.a. When linking C.o and libD.a, using
gcc C.o libD.asymbol X cannot be found.
Reasonably complicated, but on a basic level, it seems that the linker can't resolve symbols that are in files in an 'ar' file, from other places in the 'ar' file. And that's exactly what was happening, and only on OSX.
It turns out, that much like a dear friend relates about how IBM ''fixed'' awk back in the day. Apple has ''fixed'' libtool and ranlib.
-c Include common symbols as definitions with respect to the table
of contents. This is seldom the intended behavior for linking
from a library, as it forces the linking of a library member
just because it uses an uninitialized global that is undefined
at that point in the linking. This option is included only
because this was the original behavior of ranlib. This option
is not the default.
Apple have 'added' the -c flag to ranlib, to restore the behaviour that someone using the tool would expect to occur, but Apple in their wisdom have decided to remove.
Now the project in question will make a snarky remark in the ./configure stage if it detects a non-GNU ranlib, and add the -c flag.