Eliom runtime failure loading a module, but not another?

Can anyone help with ocsigenserver/eliom issue? I wrote 3 projects with a module each (A,B,C) and opam-pinned each project. And then I used 2 (A & B) in an ocsigen/eliom project. I do not know if it is relevant, but module A depends on module B. Module C does not depend on any project I wrote. Compilation always succeeds without complaint, with or without debug option in Makefile.options. Usage only with module C in the eliom file works at runtime. Usage at runtime with module A fails with the message: .cmxs: error loading shared library: /local/lib//.cmxs: undefined symbol: caml__<function_in_moduleA>_8426. That function is declared in the mli although not with that slightly mangled name. Makefile.options lists all the projects, A,B and C. I experimented with the order in which packages are listed in Makefile.options; I recall that in the past it seemed that order matters, but the ordering is correct. Changing the order does not help, although it does not appear to introduce any new error messages.

I thought perhaps using the linkall and debug options in the Makefile for A might be the culprit, since Module C works fine without those, even though I would think the linkall flag would be needed or would not hurt. But removing them does not help.

I now also make sure I compile all modules I write to every possible output I could possibly need: .a, .cma, .cmi, .cmo, .cmx, .cmxa, .cmxs, and .o files, but that doesn’t help either. This is also code that used to compile and run just fine until I recently upgraded to eliom 6.2. I repeated this same result on another machine with a fresh install of ocaml 4.02.3 under opam 1.2.2 and eliom 6.2.0. Since first posting, and downgrading to Eliom 5.0, it seems my memory is fuzzy but I still get the exact same bhavior and error message.

Is there anything else I should check? The fact that one of 2 shared libraries is loading fine is especially perplexing.

Thank you.

I have no precise idea, but here are some hints:
Do you have the same problem with the bytecode version of Ocsigen server and cmo or cma modules?
Did you load both B and A from config file (in right order)?
Did you try to simplify your code to make the cause of error more obvious?
Hope this helps,

After a lot more trial and error I finally discovered my error. I had been migrating away from OMake to ocamlbuild for one of the 3 modules in question–the one that was failing. And I re-wrote the META files. And I forgot to include 2 lines: archive(byte)(<foo>.cma) archive(byte)(<foo>.cmxa). I guess I forgot about that requirement…I don’t write META files every day.

I read up on ocamlfind and META files to better understand what they do. In so doing I realize now–being largely ignorant of how opam and ocamlfind, and eliom in this case, go about doing what they do–that .opam files and opam itself seems largely like an improvement over ocamlfind and META files, but Opam has not replaced ocamlfind and the META files. Perhaps Opam was never intended to replace ocamlfind. But for whatever reason opam files are repetitive and redundant in many respects with META files. Why do we need to specify required dependencies in both META files and opam files? I largely ignore the META files for this purpose and rely only on Opam to check required dependencies; perhaps this will sink me one day. But I thought I could ignore the META files almost entirely.

I had forgotten that without the META file list of provided cma and cmxa files I would be dead in the water, even if the needed files and opam are present. I have no idea why we need to specify these in the first place in META files. How hard is it to search the installation directory into which Opam has placed the compiled files? I had thought that with opam present and the needed files, eliom would find the needed libraries and everything would work. But I guess it makes sense…ocamlfind and META files are much older than .opam files and a lot of legacy code still depends on them and whatever protocol they established for searching for libraries.