Darren New wrote:
> There's no good way under Linux (without walking thru /proc and trying to
> parse it, and hoping it doesn't change while you do so) of telling what
> DLLs a given program is using that isn't in a package. There's also no
> good way of telling what programs are running right now.

fuser and lsof can tell you what programs currently have a certain file 
open. Probably it's race-condition-prone. Probably theu work by walking 
through /proc and parsing it.

> There's also no good way
> of figuring out if a currently-running program is compatible with the new
> DLL you just downloaded, even if that running program hasn't loaded that
> DLL.

If a shared library is ABI-incompatible, it will have a different soname, 
which means it will have a different *filename* too. Programs linked to the 
old version of the library won't be *able* to load the new version, and 
viceversa.

> (For example, you have your media player running, and you update the media
> player executable and all the codecs. But now you go back to the running
> media player and play a different file, which loads the new codec DLL that
> is now incompatible with the running executable.)

For dynamically-loadable libraries like that, it may need a custom solution, 
such as a function (with stable ABI by itself!) that can be called to ask 
the codec's ABI version, so the media player can tell if it's compatible.

Or don't break the compatibility to begin with ;)

Post a reply to this message