s3team
commented
6 years ago Thanks Stephen! We’ll look into this.
Dinghao
From: Stephen McCamant [mailto:notifications@github.com] Sent: Wednesday, December 6, 2017 6:19 PM To: s3team/uroboros uroboros@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [s3team/uroboros] ocamlbuild "-ocamlopt" option with newer ocamlbuild (#3)
This afternoon I tried building Uroboros using a generally similar but newer system than the recommended one: 64-bit Ubuntu 14.04, with a locally-compiled OCaml 4.05.0, and the library dependencies installed using a locally-compiled OPAM. (The local compilation is because this is a centrally-administered machine where we don't want to hassle the sysadmins to install every package we might want for research.) Once I got all the dependencies, there was just one more hiccup getting the compile to work.
The "src/build" script passes the "-ocamlopt" option to ocamlbuild twice; from context it seems like the intent of this option is to supply extra options to ocamlopt:
... -ocamlopt "-inline 20" -ocamlopt -nodynlink
However that didn't seem to have the desired effect with my current version of ocamlbuild (version 0.12.0, compiled outside OPAM because camlp4 needs it and also needs to be compiled outside OPAM). As far as I can see, the meaning of the -ocamlopt option in this version is a string to be used as the name of the ocamlopt program, and if it's repeated, only the last occurrence takes effect. So the supplied build file has the effect of replacing "ocamlopt" with "-nodynlink" in the ocamlfind command, which causes the native compilation steps to produce a somewhat strange ocamlfind command-line syntax error.
My guess at an option that would have the desired effect was:
... -ocamlopt "ocamlopt -inline 20 -nodynlink"
After making that change, the compilation seemed to complete successfully. Though I should also mention it seemed to compile OK if I removed the -ocamlopt option entirely; I think these options just control optimizations.
I haven't figured out when the behavior of ocamlbuild changed; I presume the authors will want to check what options will work on their older build system to find the most compatible fix.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/s3team/uroboros/issues/3, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AMy9mNXJ-tmtwsLv4fGfPO6zPYPeEbMUks5s9yDugaJpZM4Q4vx0.
This afternoon I tried building Uroboros using a generally similar but newer system than the recommended one: 64-bit Ubuntu 14.04, with a locally-compiled OCaml 4.05.0, and the library dependencies installed using a locally-compiled OPAM. (The local compilation is because this is a centrally-administered machine where we don't want to hassle the sysadmins to install every package we might want for research.) Once I got all the dependencies, there was just one more hiccup getting the compile to work.
The "src/build" script passes the "-ocamlopt" option to ocamlbuild twice; from context it seems like the intent of this option is to supply extra options to ocamlopt:
However that didn't seem to have the desired effect with my current version of ocamlbuild (version 0.12.0, compiled outside OPAM because camlp4 needs it and also needs to be compiled outside OPAM). As far as I can see, the meaning of the -ocamlopt option in this version is a string to be used as the name of the ocamlopt program, and if it's repeated, only the last occurrence takes effect. So the supplied build file has the effect of replacing "ocamlopt" with "-nodynlink" in the ocamlfind command, which causes the native compilation steps to produce a somewhat strange ocamlfind command-line syntax error.
My guess at an option that would have the desired effect was:
After making that change, the compilation seemed to complete successfully. Though I should also mention it seemed to compile OK if I removed the -ocamlopt option entirely; I think these options just control optimizations.
I haven't figured out when the behavior of ocamlbuild changed; I presume the authors will want to check what options will work on their older build system to find the most compatible fix.