It would be useful in build systems like SCons and CMake to be able to elide unnecessary linking of dependent shared libraries if a dependency only changed implementation, not ABI. One way to do that, for SCons, is described here: http://comments.gmane.org/gmane.comp.programming.tools.scons.user/26967 The technique uses the output of abidw, but simply feeds that into md5 to generate a hash, and then changes the SCons out-of-date detection for shared libraries to consider a library as up to date if the ABI hashes of its dependencies are unchanged. Presumably, an 'abihash' utility could be somewhat faster, as it wouldn't need to emit XML at all and could simply update an internal hash state as it walked the ABI. The utility should return the same md5 (or other hash?) value for two libraries if they have an identical ABI, and different hashes if the ABIs differ.
Hey Andrew, unless it matters strongly, I'd much prefer using at least SHA-1 as the hash of choice, because of FIPS-compliance. WDYT?
I think it would be OK. It would cause a little impedance mismatch for my particular use case, where SCons I think does want an MD5 sum. But since the hashes are being used for indexing into a cache, I could probably just chop off the extra bytes and pretend it was md5. I'm also not totally clear on whether SCons really actually cares if the signature is any particular number of bytes. It might just work fine to just use the full sha1 result. I'd hope it would work? I suppose another option would be to have abihash take flags, like --md5 or --sha1. Then a FIPS build could just error on the attempt to use a forbidden hash.
There is a possibility that we wouldn't have to consider this at all. FIPS mostly aims at randomization,crypto and security, and I'd hope "abihash" won't be used for these purposes, but I just want to make sure...I'll run around the office and bug some crypto guy ;)