In Ekam's link stage, it starts with a root object (typically, something exporting the symbol `main`) and then tries to satisfy all missing symbols using other built objects, transitively, until none of the remaining missing symbols are satisfied by any known objects. It then hopes those remaining symbols will be covered by libraries specified by the `LIBS` environment variable and so invokes the linker.
Ekam could additionally at this point consult an index of symbols exported by libraries in order to decide which ones to link against. We just need to implement such an index and decide how exactly a library gets included in the index.
I haven't implemented this because with Sandstorm we prefer instead to bring most of the source code for our dependencies into our build tree, so that they are in fact all built with Ekam instead of linking with pre-built system libs. This makes sense for Sandstorm since we intend to run in a chroot environment anyway and so cannot really share libraries with the rest of the system regardless. It's also really nice for development to be able to edit dependencies directly when needed and start using those changes in Sandstorm code without having to install the new library version somewhere as an interim step.
With proper caching it could make local build systems obsolete for many purposes. Maybe it would be easier then to delegate module building in style similar to distcc, but less fragile.
Because I like to walk down the memory lane I've looked at my HN comments regarding modules. Here is one from exactly one year ago [1], 855 days ago [2], 1100 days ago.
[1]: https://news.ycombinator.com/item?id=7491149 [2]: https://news.ycombinator.com/item?id=4836499 [3]: https://news.ycombinator.com/item?id=3613636