when was the last time a system needed a separate ranlib step? this feels like something someone with a vendetta's evaluated
lads. the bitch with a vendetta is me. im writing the blog post. it's "30 years ago"
behold post 015. where da lib runnin, which analyses the perennial "when was the last time a system needed a separate ranlib step?" question (alongside, unfortunately, more UNIX lineage than anyone should care for) https://nabijaczleweli.xyz/content/blogn_t/015-ranlib.html
@nabijaczleweli I don't know about other systems, but on Solaris, Sun originally shipped Solaris 2.0 without a ranlib command, and later added a shell script that only had "exit 0" to deal with complaints about breaking builds of libraries that still called it.
@alanc im wondering because POSIX specifies ar to say "the index is always generated" in a tone that makes clear the editor is annoyed at users asking
allthewhile ossp-eperl (1997) probes for ranlib in its autohell, and that documentation says "projects that build libraries want this :)"
so that, in light of, Solaris 2 (1992?) not having it, certainly makes little sense. too me
@alanc ah but indeed it's congruent — v1-v7/SysIII/SysV don't seem to have it, so naturally SunOS 5 doesn't, and per the CSRG CDs, it first appears in 4BSD as ranlib(1) ("convert archives to random libraries", hence the weird name), so naturally SunOS 4 did
@alanc (well, my source for sys3/sys5 is "a dump from my good friend vetus", but this seems to support your real+verifiable SunOS dump, so)
@nabijaczleweli Meaning RANLIB might as well be set to /bin/false by default on some systems to clear out the antique mess.
@lanodan i mean, by definition, unless you're using ar -S (and let's be real, you aren't), you can have RANLIB=true (effectively like SunOS) and you're not losing anything; so that sounds mighty complicated to do instead of /ranlib/d and /RANLIB/d
and if you /are/ somehow using ar -S, then just run ar -s after instead of ranlib
@nabijaczleweli Yeah having a noop ranlib command (like a symlink to /bin/true) is probably a good enough way to keep compatibility, but it's also just backwards compat for code that's very historic if not possibly broken, like if it would expect a file update like GNU binutils and LLVM do.
@lanodan no for sure, but lest we forget: the current autohell recommendation is that you detect and use ranlib. that's the crazy bit to me