Re: [Caml-list] 4.04 linker woes

[Gabriel Scherer <gabriel.scherer@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4646 bytes --]

I am not sure (I haven't tested the failing build).

I use
  ocamlobjinfo $(ocamlfind query compiler-libs.common)/ocamlcommon.cma
to see what is present in the archive.

One possible explanation for the behavior of utop is that requiring the
package adds the compiler-libs location to the include path, and therefore
lets utop find the package when you ask for it. But the compilation of a
binary that uses this module would still fail at link-time. (On the other
hand, I'm not sure why a binary would need this module.)

In the example below, using compiler-libs.bytecomp instead of
compiler-libs.common fixes linking. (compiler-libs.optcomp also fails.)

$ echo "let _ = Compplugin.load" > test.ml
$ ocamlfind ocamlc -package compiler-libs.common -linkpkg test.ml
findlib: [WARNING] Interface topdirs.cmi occurs in several directories: ...
File "test.ml", line 1:
Error: Required module `Compplugin' is unavailable
$ ocamlfind ocamlc -package compiler-libs.bytecomp -linkpkg test.ml
findlib: [WARNING] Interface topdirs.cmi occurs in several directories: ...
$


On Mon, Nov 7, 2016 at 3:46 PM, Christoph Höger <
christoph.hoeger@tu-berlin.de> wrote:

> I am going to give the workaround a try tomorrow.
>
> Regarding the bug, are you sure about that?
> When I load the common libs in utop, the module is loaded.
>
> utop # #require "compiler-libs.common";;
> ─( 21:39:56 )─< command 1
> >───────────────────────────────────────────────────────────
> ────────────────────────────────────────────────────────────
> ────────────────────────────────────────────────────────────
> ────────────────────────────────────────────────────────────
> ─────────────────────────────────────{
> counter: 0 }─utop # #typeof "Compplugin";;
> module Compplugin : sig val load : string -> unit end
>
>
> So if the module is not part of the common library, how do I reproduce
> the actual bug?
>
> Am 07.11.2016 um 21:30 schrieb Gabriel Scherer:
> > Compplugin is a module from the compiler distribution that indeed is new
> > in 4.04.0. It is not included in ocamlcommon.cma. It is part of
> > ocamlbytecomp.cma, but not of ocamloptcomp.cma, and I believe that the
> > latter omission is a bug (as Optcompile depends on it), so maybe it
> > should really be in ocamlcommon.cma.
> >
> > This looks like an upstream bug (in the OCaml distribution). Could you
> > open a Mantis issue?
> >
> > As a workaround, you may be able to link to the compplugin module
> > separately, it is installed in the $(ocamlfind query compiler-libs)
> > directory.
> >
> > On Mon, Nov 7, 2016 at 3:10 PM, Christoph Höger
> > <christoph.hoeger@tu-berlin.de <mailto:christoph.hoeger@tu-berlin.de>>
> > wrote:
> >
> >     Dear all,
> >
> >     today I attempted to migrate my stack towards 4.04.0 - unfortunately
> >     ppx_monadic is not yet available for that language version. I
> attempted
> >     to build it myself, but to no avail:
> >
> >     Error: Required module `Compplugin' is unavailable
> >
> >     This error is newly introduced into 4.04.0 (and does not exist in the
> >     HEAD version). Compplugin should be provided by compilerlibs.common,
> so
> >     I assume I need to fix the build system somehow.
> >
> >     Does anyone have any idea how to fix this?
> >
> >     regards,
> >
> >     Christoph
> >     --
> >     Christoph Höger
> >
> >     Technische Universität Berlin
> >     Fakultät IV - Elektrotechnik und Informatik
> >     Übersetzerbau und Programmiersprachen
> >
> >     Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin
> >
> >     Tel.: +49 (30) 314-24890 <tel:%2B49%20%2830%29%20314-24890>
> >     E-Mail: christoph.hoeger@tu-berlin.de
> >     <mailto:christoph.hoeger@tu-berlin.de>
> >
> >
>
>
> --
> Christoph Höger
>
> Technische Universität Berlin
> Fakultät IV - Elektrotechnik und Informatik
> Übersetzerbau und Programmiersprachen
>
> Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin
>
> Tel.: +49 (30) 314-24890
> E-Mail: christoph.hoeger@tu-berlin.de
>
>

[-- Attachment #2: Type: text/html, Size: 6124 bytes --]