Unbound module Ocsimore on client-side while compiling ocsigen.org

[balat]

I'm currently facing another problem while trying to update ocsigen.org.

$ js_of_eliom -c -package ocsimore_client.site src/site_doc_menu.eliom
File "src/site_doc_menu.eliom", line 9, characters 14-28:
Error: Unbound module Ocsimore

As if module Ocsimore were not linked anymore (on client side)?
Or because the findlib packages changed?

[kit-ty-kate]

The package exists, otherwise it would raise an error.
The module Ocsimore is not linked anymore in the findlib package but it is used for compiling the binary (the .js).
Is it working if you just remove the let _link = Ocsimore._link ?

[balat]

Why is it not linked anymore?
It was here precisely to be sure that ocsimore would be linked on client side.
If I remove the line, I guess this will break this ...

[kit-ty-kate]

But you can replace it by let _link = () instead if you want.

It is not linked anymore because it's a useless module for the library.
By the way, is that js_of_ocaml have the same behavior as before for linking ? Do we still have to prevent unused modules with this _link thing ?

[balat]

Ok then if it is not needed anymore, I remove it :)

I am not aware of any change in js_of_ocaml about linking.
I don't know exactly what is the problem and why there was the _link stuff ...
Would be interesting to reproduce the problem on a small example ...

[balat]

Reopening this bug temporarily, as this file is actually required.
If we do not use this _link valur from the client side program, many modules are not linked and the js program fails at startup.

BUT: I think this was only a workaround for a problem in eliomc.
On client side, perhaps ocamlc should always be called with -linkall?
@benozol do you have an idea about this?

[kit-ty-kate]

Did you try with let _link = () ?

[balat]

let _link = () will have no effect. (I don't understand what you expect this to do??)
One must reference a value from module Ocsimore, otherwise this module will not be linked.
The goal of module Ocsimore is to refer Page_site, Wiki_ext, etc, to be sure they are not removed during linking. And using Ocsimore._link from the main program will make sure that Ocsimore itself is kept in the executable.

[hhugo]

@jpdeplaix
oasis seems to link files in the wrong order ocsimore_client.cma should come before wiki_client.cma

/builds/ocsigen/4.01.0/bin/ocamlfind ocamlc -linkpkg -g -linkpkg -package eliom.client src/wiki/client/wiki_client.cma src/core/client/ocsimore_client.cma src/site/client/core_site_client.cma src/site/client/ocsimore.cmo -o src/site/client/ocsimore.byte

File "_none_", line 1:
Error: Error while linking src/wiki/client/wiki_client.cma(Wiki_types):
Reference to undefined global `Opaque'

[kit-ty-kate]

@balat is this issue fixed ? Should we create a new specific issue (in js_of_ocaml) in order to remove the _link hack ?

[balat]

No it's not. And I'm not sure whether the problem is in js_of_ocaml or in js_of_eliom. There is already a ticket for this in Eliom's bug tracker. ocsigen/eliom#87

[kit-ty-kate]

js_of_eliom is not used in ocsimore.

[kit-ty-kate]

And why is it not fixed ?

[balat]

Mainly because we do not fully understand the problem, I guess ...
If js_of_eliom is not used, something equivalent is used.
We have the problem in ocsigen.org, which is not using directly ocsimore.js, but a custom version that includes features from ocsforge and ocsigen.org. The problem has been reported in many other apps too (even if I don't know exactly where) ...

[kit-ty-kate]

By « this issue » I mean the Unbound module problem.

[balat]

Ok sorry. I don't know I didn't try ...

[hhugo]

js_of_eliom is used to compile the client part of ocsigen.org.
it calls internally ocamlc -o *.exe ... eliom_client_site.cma.
Without the linkall option, it will just drop unused code.

I think the fix is as simple as adding -linkall here https://github.com/ocsigen/eliom/blob/master/src/tools/eliomc.ml#L268

[hhugo]

cross ref ocsigen/eliom#100