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