It’s been a few days since any updates, sorry. I wanted to wait until I had something exciting to share, but it look like that might be a few more days.
The CTF utils are coming along, although, not as quickly as I’d like them to be. I’m working hard on them, but my limited knowledge about the way the internals of our build system works is throwing me off a little bit. This morning I had Colin come over to my cube and explain to me why I had so many “undefined references” to functions that I was sure were linked in. It only took a few moments for him to figure it out, where it took me most of the afternoon yesterday to come up blank. Apparently, when you statically link a library into another library, it basically just gets a container of the library’s object files. Let’s use an example to make this easier. Let’s say I have foo and bar in my build tree; foo is my library, that I want to build so I can link to it from an application, and bar is a pre-built library that contains some of the functionality I need for libfoo. If I were to add “LIBS += barS” to my common makefile, and then run “make spotless hinstall install” (under the QNX toolset), then libbarS.a, which is merely a container holding all the object files from libbar, I would have a complete libfoo.so. If I were to then try to include libfoo into my application, let’s call the application “util,” then I would add
LIBS += foo
#or
LIBS += fooS
to my common makefile for util. If I were to then run make for util, ld would error out because it can’t see the symbols that libfoo requires from libbar. This is because ld can’t see the *.a container contained within libfooS.a, so in order to statically link the libraries to the application, I would have to add
LIBS += barS fooS
to my common makefile, either that, or let the linker find the symbols automagically from the shared objects by using
LIBS += bar foo
The greatest surprise for me about this whole endeavour was not only that the static libraries inside of a library can’t be referenced by ld, but rather, that ld can’t handle linkage dependencies. Someday I would like to see ld be able to link a library into an application, and have all the libraries that are linked to that library be automatically linked. For example, if I had libfoo1 libfoo2 libfoo3, all of which are dependencies for libbar1, and an application foobar, I want to see make/ld be able to link libfoo* to libbar1, and then only be required to link libbar into foobar. All the information that’s required by the linker to do this at compile/link time should already be provided by the library being linked into foobar. Who knows, if I get enough time, eventually I may be able to make those changes, for now, though, I’m just going to sit back and complain.
I’ll post again when I’ve got more to say.
