Pyml installation can't find stdcompat

I’m trying to install pyml, and it keeps failing to find stdcompat. FWIW, I’m on a recent OpenSUSE Tumbleweed.

dfeuer@squirrel:~/src/potato> opam --version

dfeuer@squirrel:~/src/potato> opam switch create brand ocaml-base-compiler.4.10.2

<><> Gathering sources ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
[ocaml-base-compiler.4.10.2] found in cache

<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
∗ installed base-bigarray.base
∗ installed base-threads.base
∗ installed base-unix.base
∗ installed ocaml-base-compiler.4.10.2
∗ installed ocaml-config.1
∗ installed ocaml.4.10.2
# Run eval $(opam env) to update the current shell environment

dfeuer@squirrel:~/src/potato> eval $(opam env)
dfeuer@squirrel:~/src/potato> opam install pyml
The following actions will be performed:
  ∗ install conf-m4   1        [required by ocamlfind]
  ∗ install ocamlfind 1.8.1    [required by pyml]
  ∗ install stdcompat 15       [required by pyml]
  ∗ install pyml      20210226
===== ∗ 4 =====
Do you want to continue? [Y/n] y

<><> Gathering sources ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
[ocamlfind.1.8.1] found in cache
[pyml.20210226] found in cache
[stdcompat.15] found in cache

<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
∗ installed conf-m4.1
∗ installed ocamlfind.1.8.1
∗ installed stdcompat.15
[ERROR] The compilation of pyml failed at "/home/dfeuer/.opam/opam-init/hooks/ build make all pymltop PREFIX=/home/dfeuer/.opam/brand".

#=== ERROR while compiling pyml.20210226 ======================================#
# context     2.0.7 | linux/x86_64 | ocaml-base-compiler.4.10.2 |
# path        ~/.opam/brand/.opam-switch/build/pyml.20210226
# command     ~/.opam/opam-init/hooks/ build make all pymltop PREFIX=/home/dfeuer/.opam/brand
# exit-code   2
# env-file    ~/.opam/log/pyml-15995-0f1b61.env
# output-file ~/.opam/log/pyml-15995-0f1b61.out
### output ###
# ocamlfind: Package `stdcompat' not found
# Makefile:76: *** stdcompat module not found: please specify the path with STDCOMPAT=....  Stop.

<><> Error report <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
┌─ The following actions failed
│ λ build pyml 20210226
┌─ The following changes have been performed
│ ∗ install conf-m4   1
│ ∗ install ocamlfind 1.8.1
│ ∗ install stdcompat 15

The former state can be restored with:
    opam switch import "/home/dfeuer/.opam/brand/.opam-switch/backup/state-20210311161208.export"

Just to check:

dfeuer@squirrel:~/src/potato> ocamlfind query stdcompat
ocamlfind: Package `stdcompat' not found
dfeuer@squirrel:~/src/potato> opam install stdcompat
[NOTE] Package stdcompat is already installed (current version is 15).

dfeuer@squirrel:~/src/potato> opam show stdcompat

<><> stdcompat: information on all versions <><><><><><><><><><><><><><><><><><>
name                   stdcompat
all-installed-versions 15 [/home/dfeuer/src/tezos testing-inst brand]
all-versions           0  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15

<><> Version-specific details <><><><><><><><><><><><><><><><><><><><><><><><><>
version       15
repository    default
url.src:      ""
url.checksum: "sha512=1f4a9f98fa478360b8202bb5753a731d69fbafd7d964b96edefcc56100d78cdc5489faaf2c0bb1a4ee27949601a823ae3539f83f3ee4bf11bc2da18aea276899"
homepage:     ""
bug-reports:  ""
dev-repo:     "git+"
authors:      "Thierry Martinez <>"
maintainer:   "Thierry Martinez <>"
license:      "BSD-2-Clause"
depends:      "ocaml" {>= "3.08"}
depopts:      "result" "seq" "uchar" "ocamlfind"
synopsis      Compatibility module for OCaml standard library
description   Compatibility module for OCaml standard library allowing programs to use some recent additions to the OCaml standard library while
              preserving the ability to be compiled on former versions of OCaml.

You can try to reinstall stdcompat with more verbosity to see where it installs its files.

$ opam reinsall stdcomat --verbose
-  /usr/bin/install -c stdcompat__result.cmt stdcompat__bool.cmt stdcompat__fun.cmt stdcompat__format.cmt stdcompat__printf.cmt stdcompat__stdlib.cmt stdcompat.cmt '/home/kakadu/.opam/4.12.0+fp+flambda/lib/stdcompat'
- make[1]: Leaving directory '/home/kakadu/.opam/4.12.0+fp+flambda/.opam-switch/build/stdcompat.15'
-> installed stdcompat.15

That produces a slew of info, none of which I know how to interpret. I’ve collected it in this gist; does it give you some clue as to what’s going wrong?

It seemed to have install its META file in /home/dfeuer/.opam/brand/lib64/stdcompat. IIRC The META is the one used by ocamlformat to get info about packages.

Can you check that the content of that file is somewhat similar to other META files in your opam folder?
Can you check whether other libraries are installed in lib64 or in lib? On my machine everything is on lib. I wonder if the install method of stdcompat picks up something different from your environment that would explain the different path it installs in?
Can you check what ocamlfind printconf outputs? Mines mention lib/ in its “Search path:”

One line of the configure output shows that it’s loading a configuration file from your distribution. This likely overrides the libdir configuration variable to use lib64 instead of lib. None of the OCaml tools support this convention, as far as I am aware.
You can try the command unset CONFIG_SITE; opam reinstall stdcompat and see if it works better.

1 Like

@vlaviron: Wow… I had no idea that environment variable existed, let alone that it would affect OCaml installation. Unsetting it indeed fixes that! What do you suggest I do to make sure opam never sees that again?

Would you consider it a bug in the stdcompat packaging that it respects that environment variable? Or a bug in ocamlfind that it doesn’t look in lib64? Or something else? I’d like to prevent someone else from spending multiple days flailing at this silly problem.

I’m not sure honestly. I think the choice of stdcompat to use the autoconf tools is a bit unfortunate, the choice of your distro/environment to export CONFIG_SITE quite dangerous, and the support in the OCaml tools for lib64 could also be improved.
But it’s only a bug when you combine the three of them, so I’m not sure what’s the best thing to do here.

Maybe you could try submitting a bug report to stdcompat and see whether the maintainer has an opinion on that ? Then depending on the discussion there it may make sense to submit issues on other projects as well to involve more people in the discussion.

By a bizarre coincidence, about 24 hours ago I built a patch to drop the pymlstdcompat dependency (as part of an effort to use it in an opam monorepo). Depending on the priorities of the maintainers, this might be an OK approach for this problem too. I’m also happy to contribute a switch to Dune-built shim libraries in pyml, since that covers my use-case.

@David_Feuer: I encourage you to submit issues on GitHub as @vlaviron suggests, and I’ll follow the discussion closely :slight_smile:

Sorry for not having answered earlier and thank you very much for reporting! There are certainly things I have to fix to address this problem, either in pyml or stdcompat or both, but I don’t know what is the right thing(s) to do:

  1. we can drop stdcompat dependency, but it will break compatibility with OCaml <4.06 (or we have to reproduce in pyml some parts of the work done in stdcompat, in particular for floatarrays); we can also rewrite things such that there is only dependency to stdcompat when OCaml is <4.06;

  2. we can drop autotools usage in stdcompat: autotools is mainly used for preprocessing OCaml files for conditional compilation. There are probably better options, but I would prefer not to replace this autotools dependency with yet another dependency (but embedding a small ad-hoc preprocessor in stdcompat package itself can be an option);

  3. I can unset CONFIG_SITE somewhere in stdcompat's if it can help (and if it is so, it will be the simplest, short-term solution): I will try to understand more how to do that!


If I’m not mistaken, CONFIG_SITE would have to be unset before configure is run. So in the Makefile I’m afraid it would be too late.
You might be able to patch your opam file to set the variable to the empty string though.

But ultimately I wouldn’t be surprised if the real problem is that CONFIG_SITE was exported. It looks like the kind of variable that can be set locally for overriding the default for a single command, but there is also a more robust mechanism to set a system-wide configuration that wouldn’t have interfered with opam and ocamlfind.

pyml is obviously blameless here. I don’t think it should have to do anything different unless there are other reasons to do so.