I probably could be more clear about what I'm trying to convey. Tool A is written to manage mods for game B, and lots of mods for that game utilize library C. Tool A does not directly load or link to library C, but it does inspect the version of library C that currently exists alongside game B so that it can detect if mods depend on a newer version of it and notify the user that it needs to be updated.
I'm realizing now that I forgot an important detail in all of this: the metadata of the library existed as part of the metadata that the filesystem itself tracked rather than something in the contents of the file itself. This metadata doesn't seem to exist on Linux (which library C only supports if running via Proton rather than any native Linux version of the game). I could imagine it might be possible for this to be set as some sort of extended attribute on a Unix filesystem, but in practice it seems that the library will have this extended filesystem metadata when downloading the DLL onto a Windows machine (presumably with an NTFS filesystem) but not a Linux one.
> so that it can detect if mods depend on a newer version of it and notify the user that it needs to be updated.
The dynamic linker will literally tell you this, if you ask it.
> the metadata of the library existed as part of the metadata that the filesystem itself tracked rather than something in the contents of the file itself.
So does this metadata has anything to do with the file at all, or could I also attach it to e.g. an MP4 file? If that is the case than the difference is that the distributor for MS Windows did add the attribute and the distributor for GNU/Linux did not, it doesn't have anything to do with the platform.
EDIT:
> (which library C only supports if running via Proton rather than any native Linux version of the game
So library C isn't even an ELF shared object, but a PE/COFF DLL? Then that complaint makes even less sense.