> Can't say I understand why ld(1) behaves this way, though. (I'm > pretty sure I ran ranlib too.) It should've noticed _all_ the > functions in the supplied archive, right?
Not if there were no unsatisfied references to them at the time it gets to that .a in the list. With .a archives, the unit of inclusion in the link is the object file within the archive, in contrast to .so archives, where it's all or nothing. Once it's done bringing in everything from libgnumalloc.a (to use the example I cited) that was undefined at that point in the link (given how libgnumalloc keeps calloc off in a file of its own, that did not include any .o defining calloc), libgnumalloc.a is no longer available to resolve undefined references. Then, when a .o file from libc.a refers to calloc, a symbol that isn't yet present, the only version available to satisfy the reference is libc's own implementation. However, depending on the details of how the dynamic linker and the .so builder work, it may not matter. If we build it dynamic and use -lgnumalloc, yes, it will bring in all of libgnumalloc.so, but it will also bring in all of libc.so. Whether it will actually work depends on whether libc referring to a symbol defined elsewhere in libc but also defined in a different .so already included resolves to the libc version or the other library's version. (Or, if that condition is an error, it may error instead of even trying to work.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
