I am trying to do code generation with Isabelle/HOL in an M1 Mac computer. A recurring issue to achieve this relates to OCaml's library Zarith. I've asked in their mailing list and their answer was that "the problem is
ultimately to build OCaml (with Zarith) on it". Unfortunately, I do not understand what the verb "build" means in that sentence. OCaml is in that computer as the report on the end of this question indicates. The computer has Zarith on it (version 1.12). However, as they say, there is an issue with Zarith in that system. The evidence that I have for this comes from two observations:
When I run utop and do #require "zarith";; the answer is:
Cannot load required shared library dllzarith.
Reason: /.../.opam/ocaml-base-compiler.4.12.0/lib/stublibs/dllzarith.so: dlopen(/.../.opam/ocaml-base-compiler.4.12.0/lib/stublibs/dllzarith.so, 0x000A): symbol not found in flat namespace '___gmpn_add_n'.
When opening an .ml file in Visual Studio Code with commands with types such as Z.t where Z represents Zarith, VSC complains with Unbound module Z ocamllsp.
The question is then, how do I make this computer find the Zarith files it needs to work properly?
% opam config report
# opam config report
# opam-version 2.0.8
# self-upgrade no
# system arch=arm64 os=macos os-distribution=homebrew os-version=12.0.1
# solver builtin-mccs+glpk
# install-criteria -removed,-count[version-lag,request],-count[version-lag,changed],-changed
# upgrade-criteria -removed,-count[version-lag,solution],-new
# jobs 7
# repositories 1 (http) (default repo at 8818dcc3)
# pinned 0
# current-switch ocaml-base-compiler.4.12.0
Related
I'm having trouble linking a very simple OCaml program:
open Core
Format.printf "hello world %s\n" "foobar";;
Format.printf "argv= %s\n" (Sys.get_argv()).(0) ;;
which I compile with
ocamlfind ocamlc -thread -package core visitor.ml
The compile step always generates the error:
Error: Required module `Core__Core_sys' is unavailable
I've pinned version 4.0.9, and I can see the file:
$ ocamlfind query core
/home/ubuntu/.opam/4.09.0/lib/core
and $ ls -la /home/ubuntu/.opam/4.09.0/lib/core shows
-rw-r--r-- 1 ubuntu ubuntu 17891 Dec 3 20:14 core__Core_sys.cmi
-rw-r--r-- 1 ubuntu ubuntu 93777 Dec 3 20:14 core__Core_sys.cmt
-rw-r--r-- 1 ubuntu ubuntu 75659 Dec 3 20:14 core__Core_sys.cmti
-rw-r--r-- 1 ubuntu ubuntu 16958 Dec 3 20:14 core__Core_sys.cmx
I've tried everything I can think of, with no luck. BTW, I notice that the documentation https://ocaml.org/api/Sys.html makes no mention at all of get_argv but if I try just plain Sys.argv I get a warning:
# Sys.argv ;;
Alert deprecated: Core.Sys.argv
[since 2019-08] Use [Sys.get_argv] instead, which has the correct behavior when [caml_sys_modify_argv] is called.
So I conclude that the core OCaml documentation published at ocaml.org is more than two years out of date! How can one obtain up-to-date documentation, ideally documentation that describes these kinds of newbie errors?
A few points. First, it looks like you are on a fairly old version of OCaml. Unless you need to stay on 4.09 for some reason, I highly recommend upgrading to the latest version, 4.13.1. Instructions for installing are here: https://ocaml.org/learn/tutorials/up_and_running.html
In case you have any trouble with that, try upgrading to the latest version of opam (the OCaml package manager) and doing opam update to download the most up-to-date package index.
Second, it looks like you are trying to use Jane Street's Core library, which is a third-party package which is intended as a standard library replacement. As such, it has its own version of the OCaml standard library's Sys module, i.e. Core.Sys. Regarding the alert that you are getting, the Core.Sys.argv value is actually deprecated by Jane Street Core: https://ocaml.janestreet.com/ocaml-core/latest/doc/core/Core__/Core_sys/index.html#val-argv
A single result from get_argv (). This value is indefinitely deprecated. It is kept for compatibility...
This leads us to the final issue, when you try to compile it is unable to find the core package. There are a couple of choices here. First, one option is that the core package and standard library replacement are actually optional; you may not actually need them. If you're an OCaml beginner you could try sticking with the standard library only (so no open Core, no trying to compile with the core package).
Another option, if you decide to keep using the core package, is to the dune build system instead of ocamlfind. Dune is a powerful, modern OCaml build system that handles almost all aspects of package linking during the build, so you don't need to worry about issuing individual compile commands.
Here's what a dune file would look like:
(executable
(name visitor)
(libraries core))
And the visitor.ml file would be in the same directory:
let () =
Printf.printf "hello world %s\n" "foobar";
Printf.printf "argv= %s\n" Sys.argv.(0)
Then you would run:
dune exec ./visitor.exe
The .exe is a dune convention, executables across operating systems are given this extension.
Finally, in source code you never actually need ;;. More about that here: https://discuss.ocaml.org/t/terminate-a-line-with-or-or-in-or-nothing/8941/21?u=yawaramin
Note on documentation being out of date: it would help if you could point us to where you got the instructions that led you to this point of confusion. There is a lot of effort to clean up install instructions and modernize documentation, but unfortunately there are a lot of outdated getting started guides out there. The 'Up and Running' link I provided at the top of this answer is the best resource.
You need to link the package by adding the -linkpkg flag:
ocamlfind ocamlc -thread -package core -linkpkg visitor.ml
A while back, I created a fork of the RDCOMClient package to keep it working with R 3.6 (https://github.com/dkyleward/RDCOMClient). People are now running into issues again because it won't work with R 4.0. The problem doesn't seem as easy to fix, and I'm hoping for some help.
If I flip Rstudio back to R 3.6 (and rtools35), I can use the package after installing with devtools::install_github(). When I try in R 4.0 (and rtools40), the package builds and I can connect over COM to an application. The first line of code below works, and xl is a COM pointer; however, trying to do anything with it (like set Excel to visible) will crash R.
xl <- RDCOMClient::COMCreate("Excel.Application")
xl[["Visible"]] <- TRUE
Again, the above works in R 3.6.
Is there is a way to continue building with the previous rtools? I came across https://github.com/r-windows/rtools-backports#readme, which talks about using rtools35 to keep building packages, so I have hope, but I don't understand how to make it happen.
Alternatively, if there are minor changes I can make to the R or cpp code that will solve my problem, I'm all ears. I'm a cpp novice, though.
This was a quick fix :
install.packages("RDCOMClient", repos = "http://www.omegahat.net/R")
Install R-4.0.0
Install Rtools35
Edit $R_HOME/etc/x64/Makeconf (for R-4.0.0-x64)
Rcmd INSTALL RDCOMClient
Rik's answer was incredibly helpful and got a version working; however, after spending a day on it, I was able to improve on it. I want to put that here in case I have to do it again. The main improvement is being able to build a working package for both 32- and 64-bit architectures. By default, R installs both, and this makes things easier when installing dependent packages.
The first two steps are the same:
Install R-4.0.0 (https://cran.r-project.org/bin/windows/base/old/4.0.0/R-4.0.0-win.exe)
Install Rtools35 (https://cran.r-project.org/bin/windows/Rtools/Rtools35.exe) in directory c:\Rtools
If (like me) you had already installed rtools40, a system environment variable named RTOOLS40_HOME is created. The first step is to change that to:
C:\rtools
If you don't have rtools40 installed, then create the RTOOLS40_HOME system environment variable.
Two changes are still needed in the make files. These are found in your R installation directory.
In etc\x64\Makeconf, add underscores to match the rtools35 directory structure by setting these values:
MINGW_PREFIX = /mingw_$(WIN)
BINPREF ?= "$(RTOOLS40_ROOT)/mingw_64/bin/"
Do the same in etc\i386\Makeconf:
MINGW_PREFIX = /mingw_$(WIN)
BINPREF ?= "$(RTOOLS40_ROOT)/mingw_32/bin/"
Do not set BINPREF as an environment variable, or this will overwrite the makefile changes (like RTOOLS40_HOME does). With these complete, finish off with the same steps that Rik outlined:
Open windows command prompt and change to the directory that contains the RDCOMClient subdirectory and type:
R CMD INSTALL RDCOMClient –-build RDCOMClient.zip
This installs RDCOMClient in the local installation of R-4.0.0 and additionally creates the file RDCOMClient_0.94-0.zip that can be installed on other systems using the following command:
install.packages("RDCOMClient_0.94-0.zip", repos = NULL, type = "win.binary")
I can confirm that the procedure delineated in the answer above leads in the right direction but a few extra steps may be required. I can also confirm that the procedure below produces a Windows binary file that can be installed and will run under R-4.0.0:
Install R-4.0.0 (https://cran.r-project.org/bin/windows/base/old/4.0.0/R-4.0.0-win.exe)
Install Rtools35 (https://cran.r-project.org/bin/windows/Rtools/Rtools35.exe) in directory c:\Rtools
Edit $R_HOME/etc/x64/Makeconf (for R-4.0.0-x64) by changing
## The rtools40 installer sets RTOOLS40_HOME, default to standard install path
RTOOLS40_HOME ?= c:/rtools40
to
## The rtools40 installer sets RTOOLS40_HOME, default to standard install path
RTOOLS40_HOME ?= c:/rtools
Download RDCOMClient-master.zip from https://github.com/omegahat/RDCOMClient (click the green Clone button and select download zip)
Unpack to a directory named RDCOMClient
Ensure that the following PATH variables are set:
C:\Program Files\R\R-4.0.0\bin\x64 (assuming this is the location where R is installed)
C:\Rtools\bin
C:\Rtools\mingw_64\bin
Add environment variable BINPREF with the following value (the final slash is important):
C:/Rtools/mingw_64/bin/
Open windows command prompt and change to the directory that contains the RDCOMClient subdirectory and type:
R CMD INSTALL RDCOMClient –-build RDCOMClient.zip
This installs RDCOMClient in the local installation of R-4.0.0 and additionally creates the file RDCOMClient_0.94-0.zip that can be installed on other systems using the following command:
install.packages("RDCOMClient_0.94-0.zip", repos = NULL, type = "win.binary")
I am using R 4.1.2 and I found RDCOMClient will crash the R Session and the above solutions were not working.
Then, I further check with the source owner and found out the solution.
https://github.com/omegahat/RDCOMClient/issues/36
Duncantl gave the solution and it works.
dir.create("MyTemp")
remotes::install_github("BSchamberger/RDCOMClient", ref = "main", lib = "MyTemp")
If that is successful, we can then load the newly installed package with
library("RDCOMClient", lib.loc = "MyTemp")
I am getting the same error when trying to install many ports with MacPorts, e.g. gtk2:
~ sudo port install gtk2
Password:
---> Computing dependencies for gtk2
The following dependencies will be installed:
clang-4.0
clang-5.0
graphite2
harfbuzz
ld64
ld64-latest
libmacho-headers
libomp
llvm-5.0
pango
perl5
xar
xorg-libXcomposite
xorg-libXcursor
xorg-libXdamage
xorg-libXinerama
xorg-libXrandr
xorg-util-macros
Continue? [Y/n]:
---> Configuring clang-4.0
Error: clang-4.0 has been replaced by clang-8.0; please install that instead.
Error: Failed to configure clang-4.0: obsolete port
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-4.0/clang-4.0/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port gtk2 failed
The installation here suggests to install clang-4.0, among others, to which I can only answer "Continue".
However, it then fails claiming that very same port is "obsolete". Suggesting to install 8.0 instead.
However, I already have it installed by MacPorts:
~ clang -v
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-apple-darwin12.6.0
Thread model: posix
InstalledDir: /opt/local/bin
➜ ~ which clang
/opt/local/bin/clang
What is wrong here and why do MacPorts insist on installing an obsolete port dependency?
UPDATE1. Some troubleshooting attempts...
➜ ~ port installed|grep llvm
cctools #921_2+llvm37 (active)
llvm-3.7 #3.7.1_4 (active)
llvm_select #2_0 (active)
➜ ~
UPDATE2.
~ sudo port uninstall lldb-4.0
Warning: no such port: lldb-4.0, skipping uninstall
➜ ~ sudo port uninstall clang-4.0
➜ ~ sudo port uninstall clang_select
---> Deactivating clang_select #2_0
---> Cleaning clang_select
---> Uninstalling clang_select #2_0
---> Cleaning clang_select
➜ ~
However, clang-8.0 is installed and working:
~ clang -v
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-apple-darwin12.6.0
Thread model: posix
InstalledDir: /opt/local/bin
➜ ~ clang
clang-8: error: no input files
➜ ~
Then why isn't it found by the MacPorts?
➜ ~ sudo port install gtk2
---> Computing dependencies for gtk2
The following dependencies will be installed:
clang-4.0
...
Can I configure it to be found in /opt/local/bin instead of trying to install the old clang-4.0?
UPDATE3.
My config directories:
➜ ~ ls /opt/local/etc/macports
archive_sites.conf macports.conf.default sources.conf variants.conf.default
archive_sites.conf.default pubkeys.conf sources.conf.default
macports.conf pubkeys.conf.default variants.conf
➜ ~
➜ ~ less /opt/local/etc/macports/macports.conf
# MacPorts system-wide configuration file.
# Commented-out values are defaults unless otherwise noted.
# Directory under which MacPorts should install ports. This must be
# where MacPorts itself is installed.
prefix /opt/local
# User to run operations as when MacPorts drops privileges.
#macportsuser macports
# Directory for MacPorts working data.
portdbpath /opt/local/var/macports
# Colon-delimited list of directories to search for external tools
# (make(1), pkg-config(1), etc.). While installing ports, MacPorts uses
# this list for PATH. Changing this setting is intended for advanced
# users only and is unsupported.
#binpath /opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin
# Directory containing Xcode Tools. By default, MacPorts determines this
# using xcode-select(1).
#developer_dir /Applications/Xcode.app/Contents/Developer
# Location of PackageMaker. Defaults to
# "${developer_dir}/Applications/Utilities/PackageMaker.app" with Xcode
# 4.2 and earlier and "/Applications/PackageMaker.app" with 4.3 and later.
#packagemaker_path /Applications/PackageMaker.app
# Directory for application bundles installed by ports.
applications_dir /Applications/MacPorts
# Directory for frameworks installed by ports.
frameworks_dir /opt/local/Library/Frameworks
# Location of the MacPorts sources list.
sources_conf /opt/local/etc/macports/sources.conf
# Location of the MacPorts global variants definition file. Optional.
variants_conf /opt/local/etc/macports/variants.conf
# When MacPorts should build ports from source.
# - ifneeded: Download binary archives if available; build from source
# otherwise.
# - always: Always build from source; never try fetching archives.
# - never: Never build from source; try fetching archives and abort if
# unavailable.
#buildfromsource ifneeded
# Type of archive to use for port images. Supported types are cpgz,
# cpio, tar, tbz, tbz2, tgz, tlz, txz, xar, zip.
#portarchivetype tbz2
# Apply transparent filesystem compression to files on activation.
# Requires bsdtar with support for --hfsCompression in binpath, which can be
# provided by installing the libarchive port. This will work with HFS+ or APFS
# volumes only and will be ignored on other filesystems.
#hfscompression yes
# CPU architecture to target. Supported values are "ppc", "ppc64",
# "i386", and "x86_64". Defaults to:
# - OS X 10.5 and earlier: "ppc" on PowerPC, otherwise "i386".
# - OS X 10.6 and later: "x86_64" on Intel 64, otherwise "i386".
#build_arch i386
# Space-delimited list of CPU architectures to target when building
# universal. Defaults to "i386 ppc" on Mac OS X 10.5 and earlier,
# "x86_64 i386" on Mac OS X 10.6 through macOS 10.13, and "x86_64" on
# macOS 10.14 and later (the 10.14 SDK is not universal).
#universal_archs x86_64 i386
# Use ccache, a compiler cache for C, C++, Objective-C, and
# Objective-C++. (See http://ccache.samba.org.) The "ccache" executable
# must exist in one of the directories in binpath.
#configureccache no
# Directory for ccache's cached compiler output.
#ccache_dir /opt/local/var/macports/build/.ccache
# Maximum size of files stored in ccache's cache. Append "G", "M", or
# "K" for gigabytes, megabytes, or kilobytes.
# Use distcc, a distributed compiler for C, C++, Objective-C, and
# Objective-C++. (See http://distcc.org.) The "distcc" executable must
# exist in one of the directories in binpath.
#configuredistcc no
# Use pipes rather than temporary files for communication between the
# various stages of C, C++, Objective-C, and Objective-C++ compilation.
#configurepipe yes
# Lowered scheduling priority to use for commands run during configure,
# build, and destroot. Accepted values are 0 (normal priority) through
# 20 (lowest priority).
#buildnicevalue 0
# Number of simultaneous make(1) jobs to use when building ports. If set
# to 0, the number of jobs will be the lesser of:
# - number of automatically-detected CPU cores
# - gigabytes of physical memory + 1
#buildmakejobs 0
# umask value to use when a port installs its files.
#destroot_umask 022
# Automatically execute "clean" after "install" of ports.
#portautoclean yes
# Keep logs after successful installations.
#keeplogs no
# The rsync server for fetching MacPorts base during selfupdate. This
# setting is NOT used when downloading ports trees; ports trees are
# configured using the file referenced by sources_conf. See
# https://trac.macports.org/wiki/Mirrors#MacPortsSource for a list of
# available servers.
#rsync_server rsync.macports.org
# Location of MacPorts base sources on rsync_server. If this references
# a .tar file, a signed .rmd160 file must exist in the same directory
# and will be used to verify its integrity. See
# https://trac.macports.org/wiki/Mirrors#MacPortsSource to find the
# correct rsync_dir for a particular rsync_server.
#rsync_dir macports/release/tarballs/base.tar
# Options to pass to rsync when fetching MacPorts base and the ports tree.
#rsync_options -rtzvl --delete-after
# Type of generated StartupItems.
# - launchd: Create StartupItems for use with launchd.
# - default: Create StartupItems for launchd on OS X and none on
# other platforms.
# - none: Disable creation of StartupItems.
# This setting only applies when building ports from source.
#startupitem_type default
# Create system-level symlinks to generated StartupItems. If set to
# "no", symlinks will not be created; otherwise, symlinks will be placed
# in /Library/LaunchDaemons or /Library/LaunchAgents as appropriate.
# This setting only applies when building ports from source.
#startupitem_install yes
# Whether to allow ports to automatically load their StartupItems.
# If set to "no", StartupItems will never be loaded unless the user
# explicitly requests it. If set to "yes" (the default), some ports may
# automatically load their StartupItems when they are activated.
#startupitem_autostart yes
# Extra environment variables to keep. MacPorts sanitizes its
# environment while processing ports, keeping:
# - DISPLAY
# - DYLD_FALLBACK_FRAMEWORK_PATH, DYLD_FALLBACK_LIBRARY_PATH,
# DYLD_FRAMEWORK_PATH, DYLD_INSERT_LIBRARIES, DYLD_LIBRARY_PATH
# - JAVA_HOME
# - ARCHIVE_SITE_LOCAL, MASTER_SITE_LOCAL, PATCH_SITE_LOCAL
# - PORTSRC
# - ALL_PROXY, FTP_PROXY, http_proxy, HTTPS_PROXY, NO_PROXY, RSYNC_PROXY
# - GROUP, USER
# - COLUMNS, LINES
# Variables listed in extra_env are added to this list. This has no
# default value; setting it is intended for advanced users and is
# unsupported. (Note that sudo(8) sanitizes its environment on OS X 10.5
# and later, so it may have to be configured to pass the desired
# variables to MacPorts.)
#extra_env KEEP_THIS THIS_TOO
# Override proxy-related environment variables. By default, MacPorts
# takes proxy settings from the environment, from the proxy_* options
# below, and from Network Preferences, in that order. If this is set to
# "yes", MacPorts uses proxy_*, then Network Preferences, then the
# environment. (Note that Network Preferences does not have a setting
# for rsync proxies. Also note that sudo(8) sanitizes its environment on
# OS X 10.5 and later, so it may have to be configured to pass desired
# variables to MacPorts.)
#proxy_override_env no
# Proxies. These have no default values. The analogous environment
# variables are "http_proxy", "HTTPS_PROXY", "FTP_PROXY", and
# "RSYNC_PROXY".
#proxy_http proxy1:12345
#proxy_https proxy2:67890
#proxy_ftp proxy3:02139
#proxy_rsync proxy4:11377
# Comma-delimited list of hosts that MacPorts should not access through
# the HTTP, HTTPS, and FTP proxies. This does not apply to rsync, and it
# has no default value.
#proxy_skip host1, host2, host3
# Space-delimited lists of glob patterns matched against download hosts
# that MacPorts should not use and that MacPorts should prefer, respectively,
# overriding the usual ping time checks. These have no default values.
#host_blacklist badhost1 badhost2
#preferred_hosts preferredhost1 preferredhost2 *.de.*.macports.org
# Whether MacPorts should automatically run rev-upgrade after upgrading
# ports.
#revupgrade_autorun yes
# Whether rev-upgrade should automatically rebuild ports with broken
# linking or merely report the breakage. Supported values are "report"
# and "rebuild".
#revupgrade_mode rebuild
# Space-delimited list of files and directories to delete after the
# unarchive stage and before creating a pkg. Paths are interpreted
# relative to prefix, and there is no default value. This is useful for
# removing unnecessary files and directories prior to pkg or mpkg
# deployment.
#pkg_post_unarchive_deletions include share/doc share/man
# Whether the user interface should ask interactive questions
#ui_interactive yes
# Added to support C++11 following https://trac.macports.org/wiki/LibcxxOnOlderSystems
cxx_stdlib libc++
buildfromsource always
(END)
I have finally solved this puzzle, thanks to a hint from a MacPorts mailing list user. He suggested to
port install <port> configure.compiler=macports-clang-8.0
that did not work for me though, because my clang8 was in /usr/bin, while if I understand correctly, MacPorts look for their own packages rather than ones installed from elsewhere,
even after I manually symlinked it to /opt/local/bin/clang.
Then I read this comment:
We kept 3.4, 3.7, and 5.0 as stepping stones. I hope I thought that through fully...I think that’s the minimal amount needed.
It then occurred to me that I can try clang-3.7 as "stepping stone", installed it, and thereafter was able to install the other ports with
port install <port> configure.compiler=macports-clang-3.7
In particular, I was also able to install clang-5.0 that way:
port install clang-5.0 configure.compiler=macports-clang-3.7
And now that I have the more recent stepping stone in the chain, the problem seems fixed with no more annoying fallbacks
to obsolete ports!
Further sources
Quote from comment to my ticket referring to the problem:
https://trac.macports.org/ticket/58747#comment:1
MacPorts base 2.5.4 still has clang 4.0 in its list of compilers, even though the port has been made obsolete: https://github.com/macports/macports-base/blob/v2.5.4/src/port1.0/portconfigure.tcl#L604
It points to the code line 604:
lappend compilers macports-clang-5.0 macports-clang-4.0
from where it appears that one of clang-4.0 or 5.0 is required. This could be the reason why it insists on installing one of these ports, defaulting to the obsolete 4.0.
I presume a fix should include adding more ports to this list, e.g. clang-3.7 that is not obsolete (with hopefully no plans to change it).
Which is currently proposed in
Relevant Github PR https://github.com/macports/macports-base/pull/137
Please add your voice to get it merged!
This is an obsoletion message. Since you already have the replacement, just uninstall clang-4.0, llvm-4.0, and lldb-4.0 and you will be fine.
I'm trying to install the uri package for Opam but I keep running in to this error.
==== ERROR [while installing uri.1.3.8] ====
# opam-version 0.9.6 (latest-103-g955b7ca)
# os linux
# command ocaml setup.ml -configure --prefix /root/.opam/system
# path /root/.opam/system/build/uri.1.3.8
# exit-code 1
# env-file /root/.opam/system/build/uri.1.3.8/uri-ffb3fd.env
# stdout-file /root/.opam/system/build/uri.1.3.8/uri-ffb3fd.out
# stderr-file /root/.opam/system/build/uri.1.3.8/uri-ffb3fd.err
### stderr ###
ocamlfind: Package `compiler-libs.toplevel' not found
W: Field 'pkg_compiler_libs_toplevel' is not set: Command ''/root/.opam/system/bin/ocamlfind' query -format %d compiler-libs.toplevel > '/tmp/oasis-85d951.txt'' terminated with error code 2
E: Cannot find findlib package compiler-libs.toplevel
E: Failure("1 configuration error")
'opam install uri' failed.
I'm pretty new to Ocaml and the Opam repo. I really have no idea what is going wrong. I am running Ubuntu 12.04 and have Ocaml 3.12.1 installed.
Thanks for any insight you can provide!
I just installing uri under 3.12.1 without any issues.
3.12.1 is under your system ocaml compiler, right? and you probably installed ocaml via aptitude? In which case you need to also install ocaml-compiler-libs. There are a number of other optional packages for OCaml that are usually needed and may run into in the future --camlp4-extra is another that I see missed and oft needed. A maximal list is here.
I would also upgrade OPAM, since there were some changes to the uri package only two days ago. opam update; opam upgrade. This will require some re-compilation, and make sure you switched to the correct compiler.
The package "compiler-libs.toplevel" is missing. If I remember right, it's shipped together with ocaml and is available only since version 4.0.
Either install an older version of uri or update your compiler to 4.0. For details look here
I'm running Ocaml 3.12 on Ubuntu installed via Godi.
I'm going through the Lwt tutorial. I've started up the toplevel and done (as instructed):
# #use "topfind";;
# #require "lwt";;
The require of "lwt" seems to be successful (no complaints about not being able to find it).
Then a bit later I try:
# Lwt_io.read_char;;
And the toplevel complains:
# Error: Reference to undefined global `Lwt_io'
When I look in ~/godi-3.12/lib/ocaml/pkg-lib/lwt I see that lwt_io.cmi and lwt_io.mli files are present. godi says I have version 2.2.1 of lwt installed.
I also tried running lwt-toplevel, but could not type anything into it...
Lwt_io module belongs to lwt.unix subpackage. Use it:
#require "lwt.unix";;