Recently I enhanced the rpm package dependencies to cover also cmx files. (In retrospection: The title and summary is misleading, it really meant just cmx/cmxa …). It turned out: cmxs files need to be handled differently, most likely not at all.
My question is: what runtime dependency information is actually contained in a cmxs file, and in an application that loads a cmxs file?
For example, ocamlobjinfo bigarray.cmxs shows imported Interfaces and Implementations, I think this means what is compiled into the cmxs, not what such cmxs would depend on.
An application does apparently not expose required runtime hashes, at least nothing obvious is shown in readelf -Wa coqtop. But they seem to exist internally. While fixing the PR mentioned above, coqtop complained about a hash mismatch in Stdarg while loading one of the Coq cmxs files (I did not make a note of the exact error message). I think as long as the application and the used cmxs files come from the same build (like coq.git), there will be no runtime mismatches.
For static linking (.cmx, .cmxa), the consistency information (the set of interfaces and implementations that a piece of code depends on) is stored as a field in the marshalled structure. Consistency is then checked at link time using this information.
For dynamic linking, the consistency check needs to be done at runtime, so we need both the loaded file and the loading code to carry their own consistency data. For the loading code (the executable), the consistency data is stored into a particular symbol (caml_globals_map). This symbol is then read by the dynlink library code to initialise the consistency data structure.
For the loaded code (the .cmxs file), it would have been possible to use a similar setup to the static linking case, with a file containing metadata as a marshalled structure and a separate .so file containing the raw code, but the current implementation also relies on storing the metadata including the consistency data in a special symbol (caml_plugin_header).
I should add that ocamlobjinfo reads the caml_plugin_header symbol on .cmxs files to print the units involved (both defined and imported), but there is no matching support for reading the caml_globals_map symbol of an executable.