Too long to tweet, too short to blog.
May 04
-
* cdleary goes to find out wtf ranlib is
-
<jimb>
cdleary: Yay!!
-
<jimb>
something bad that the Unix guys thought was really neato
-
<Wes->
cdleary: jim's answer not withstanding, on older unices, you had to "ranlib" your .a files (archives of object files) so that symbols within the library, but outside of objects could be resolved by the linker whether their definition appeared before or after first use in the library. At least, that's what my memory tells me. I was pretty green the last time I ran ranlib and it was actually...
-
<Wes->
...*necessary*
-
<jimb>
cdleary: Originally, 'ar' was a general purpose file-archiving program whose format just happened to be understood by the linker. But its use for anything but libraries gradually faded away.
-
<jimb>
And, originally, the .o files had to appear in the .a file in an order such that undefined symbols from earlier .o files would be resolved by later .o files, so the linker only needed to make a single pass through the .a file.
-
<timeless_mbp>
technically ar is still used by debian archives :)
-
<jimb>
I'm down with having simple tools that you use everywhere, but I'd argue that with those ordering requirements, the *net* simplicity wasn't optimized.
-
<cdleary>
ah interesting -- wasn't aware .a had an internal order
-
<jimb>
Well, once you've ranlibbed something, the linker consults that, and there's no internal order required any more.
-
<jimb>
Anyway, the GNU binutils did away with that, and just built the index in ar, and made the archive mutation operations keep it up to date. So it's never mattered on GNU.
