I have installed frama-c (18.0) and coqide (8.9) through opam (plus other needed dependencies of course, but that may not be the matter here). Well the point is I simply installed it through opam, not done anything else strange (and I didn't see any particular instruction that I should do otherwise).
Frama-c works as expected when I use Alt-ergo with WP, but if I try to use coq or coqide instead of Alt-ergo, then I get the following error for each goal that Qed does not manage to prove immediately:
[wp] 13 goals scheduled
[wp] [Coq] 'Qed.v' compilation failed.
------------------------------------------------------------
--- Coqc (stderr) :
------------------------------------------------------------
File "/tmp/wp7fe5dc.dir/coqwp/Qed.v", line 27, characters 8-17:
Error:
Cannot find a physical path bound to logical path matching suffix bool.
------------------------------------------------------------
[wp] [Coq] Goal typed_nondet_loop_inv_preserved : Failed
Compilation of 'Qed.v' failed.
As a note, before displaying the error, it manages to compile some other .v files. I have tried to open manually the files in coqide, and I get the same result. For the record, here are the lines coq complains about:
Require bool.Bool.
Require int.Int.
Require int.Abs.
Require int.ComputerDivision.
Require real.Real.
Require real.RealInfix.
Require real.FromInt.
I have also tried to downgrade coq a bit, but not lower than 8.7 (as otherwise opam complains of incompatible base installation package and I don't really want to screw up my installation), and got the same result.
If someone would have an idea of what is causing that and how I can get to set it up that correctly, that'd be nice. Even if for what I'm doing with it for now, Alt-ergo is sufficient, I would have liked to play a bit with coq to see how it can be used.
Regards,
--
Vincent Penelle.
First, indeed you need coq < 8.8 (e.g. 8.7.2) if you want to use it with Frama-C/WP, as newer versions are not supported for the moment.
Second, the order in which you have installed your packages is relevant. In particular, if the appropriate version of coq has been installed after frama-c, WP did not compile and install its coq libraries, which are the ones that are missing here. Thus, you may want to do opam reinstall frama-c to compile the package against a compatible coq version.
Related
I'm trying to follow this but the provided source files are failing make with this error
make[1]: Entering directory '/home/myhome/Dropbox/org/coq/cpdt'
COQC src/CpdtTactics.v
File "./src/CpdtTactics.v", line 10, characters 0-32:
Error: Cannot find a physical path bound to logical path Omega.
in CpdtTactics.v there is
...
Require Import Eqdep List Omega.
...
Where is this Omega? One reference mentioned it being deprecated. Another might have mentioned ZArith as a substitute. Also, just calling up InductiveTypes.v of the cpdt/src files and trying to evaluate line-by-line, I get
Error: Cannot find a physical path bound to logical path Cpdt.CpdtTactics.
I've got this in my custom-set-variables
'(coq-prog-args
'("-emacs -R /home/myhome/Dropbox/org/coq/cpdt/src Cpdt"))
But I'm guessing this is not necessarily my mistake, rather, coq is looking for CpdtTactics.vo and it's not there because make didn't complete? (In fact, it's not there.)
I'm on coq 8.15 and am using Emacs 28.1/Proof General Version 4.5-git.
BTW, on https://x80.org/collacoq/ Require Import Omega. seems to succeed.
The Omega module and the omega tactic have been removed in Coq version 8.14 (after being deprecated in version 8.12).
It seems that the latest CPDT tarball was not updated yet to be compatible with Coq 8.14, so this means that you should compile it with a lower version of Coq, such as version 8.13.
You can install earlier versions of Coq by relying on the Coq Platform.
If you use the Coq Platform scripts, you can rely on the latest version of the Coq Platform since it provides the option to select an earlier version of Coq. If you'd rather use the binary installers, then you can find installers for Coq 8.13 in a previous release of the Platform.
The reason why Require Import Omega works on https://x80.org/collacoq is that this website has not been kept up-to-date and is still at Coq version 8.11. If you use https://coq.vercel.app/scratchpad.html instead, you get the latest version of Coq (and thus Require Import Omega does not work).
I am working with the book Certified Programming with Dependent Types but each time I'm finding a different error. It seems to me that the error comes from a mismatch between the compilation process from Proof General and through the makefile of the sources of the book.
If I compile the sources with make and try to run for instance Subset.v in Proof-General I get:
Error: File /home/usuario/Desktop/Coq/cpdt/src/CpdtTactics.vo has
bad magic number 81100 (expected 8600). It is corrupted or was
compiled with another version of Coq.
If I clean the makefile compiled files with make clean and try to proceed with the option Coq -> Auto Compilation -> Compile before require then it is the line:
Require Extraction.
that fails. Originally it failed with the error:
Error: Unable to locate library Extraction.
but with the above option enables it gives something like:
echo "Require Extraction." > /tmp/ProofGeneral-coqQPJTf0.v coqdep -Q /home/usuario/Desktop/Coq/cpdt/src/ -R /home/usuario/Desktop/Coq/cpdt/src Cpdt /tmp/ProofGeneral-coqQPJTf0.v
* Warning: in file /tmp/ProofGeneral-coqQPJTf0.v, library Extraction is required and has not been found in the loadpath!
* Warning: in file /tmp/ProofGeneral-coqQPJTf0.v, library Extraction is required and has not been found in the loadpath!
/tmp/ProofGeneral-coqQPJTf0.vo /tmp/ProofGeneral-coqQPJTf0.glob /tmp/ProofGeneral-coqQPJTf0.v.beautified: /tmp/ProofGeneral-coqQPJTf0.v
/tmp/ProofGeneral-coqQPJTf0.vio: /tmp/ProofGeneral-coqQPJTf0.v
How can I solve this?
Side-questions: which OS are you using? do you rely on opam?
Regarding the first error you get, it certainly comes from the following fact:
outside proofgeneral, the coqc binary corresponds to Coq 8.11, while in ProofGeneral, the coqtop binary correspond to Coq 8.6. Maybe because the PATH variable is not the same in the two contexts.
To figure out which binary is found, you can do in the terminal which coqtop, and within Emacs, M-! which coqtop RET and you should thus get different paths.
Sometimes, opening emacs directly from the terminal (emacs &) can help for this kind of issue.
But if you want to change the coqtop binary that is used in ProofGeneral, you can set the coq-prog-name option, by using one of the following steps:
Interactively, type C-u C-c C-x (to kill Coq), M-: (setq coq-prog-name "…/coqtop"), and C-c C-n
Or create a .dir-locals.el file (Emacs' standard conf-file) in the project root containing:
((coq-mode . ((coq-prog-name . "…/coqtop"))))
and close/reopen the ….v file at stake (or just do M-x normal-mode RET or C-x C-v RET in the already-opened ….v buffer)
Regarding the second error you get, I'm a bit puzzled that Require Extraction triggers this error, as this library does exist in Coq 8.6 and 8.11.
At first sight, I'd suggest to re-test the auto-compilation with Coq 8.11, asserting From Coq Require Extraction. (instead of just Require Extraction.)
But maybe there is a bug in PG's Auto Compilation -> Compile before require feature; anyway feel free to open a related issue in the PG tracker if need be, bug reports and feature requests are very welcome: https://github.com/ProofGeneral/PG/issues
I've been wanting to use coq-vpl, and I have it installed. I can confirm this from opam list
ubuntu#ubuntu-xenial:~$ opam list
# Installed packages for system:
...
coq 8.6 Formal proof management system.
coq-vpl 0.2 Coq interface to VPL abstract domain of convex polyhedra.
coq-vpltactic 0.2 A Coq Tactic for Arithmetic (based on VPL).
coqide 8.6 IDE of the Coq formal proof management system.
...
However, how do I find out what the library is actually called and what I need to import? The vpl page does not have docs on it.
You can run
coqc -config
To get a list of configuration variables. On my system, this gives
LOCAL=0
COQLIB=/home/jgross/.local64/coq/coq-8.7.1/lib/coq/
DOCDIR=/home/jgross/.local64/coq/coq-8.7.1/share/doc/coq/
OCAMLFIND=/home/jgross/.opam/system/bin/ocamlfind
CAMLP4=camlp5
CAMLP4O=/home/jgross/.opam/system/bin/camlp5o
CAMLP4BIN=/home/jgross/.opam/4.02.2/bin/
CAMLP4LIB=/home/jgross/.opam/system/lib/camlp5
CAMLP4OPTIONS=-loc loc
CAMLFLAGS=-thread -rectypes -w +a-4-9-27-41-42-44-45-48-50 -bin-annot -safe-string
HASNATDYNLINK=true
COQ_SRC_SUBDIRS=config dev lib kernel library engine pretyping interp parsing proofs tactics toplevel printing intf grammar ide stm vernac plugins/btauto plugins/cc plugins/derive plugins/extraction plugins/firstorder plugins/fourier plugins/funind plugins/ltac plugins/micromega plugins/nsatz plugins/omega plugins/quote plugins/romega plugins/rtauto plugins/setoid_ring plugins/ssr plugins/ssrmatching plugins/syntax plugins/xml
If you look at the user-contrib directory of the path given by COQLIB, you should see folders with the various libraries you've installed. For any of these folder names, you can add From FolderName Require Import FileName to your Coq file.
According to https://github.com/VERIMAG-Polyhedra/VplTactic, you need to run coq, for instance by launching coqide (which you installed) and by typing the following lines in the left-hand-side window and executing them (using the downward green arrows on top of the window).
Require Import VplTactic.Tactic.
Add Field Qcfield: Qcft (decidable Qc_eq_bool_correct, constants [vpl_cte]).
And so on, please read the page at the link given above. I did not try it yet.
I would like to make a rpm which can install on RHEL5,6 and 7.
[p4474668#rhel7dev source]$ cpanspec webmin-ajax-0.00.tar.gz -d '' --force --filter-requires 'perl(:MODULE_COMPAT_5.16.3)' -b
(... lots of infos here ...)
[p4474668#rhel7dev source]$ rpm -qpR noarch/perl-webmin-ajax-0.00-1.noarch.rpm
perl(:MODULE_COMPAT_5.16.3)
perl(DST::System)
perl(WebminCore)
perl(lib)
perl(strict)
perl(warnings)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1useless
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
Since the dependancy is not removed, it cannot be installed on a RHEL5.
How to remove the perl(:MODULE_COMPAT_5.16.3) not required dependency?
This feature is under-documented, and doesn't (IMHO) do all of what its name implies.
What it does is:
along with the .spec file it creates a filter script file (some sed in a .sh script), this is referenced in the .spec file and is required during rpmbuild. The dependencies written to the .spec file are not affected by filtering.
that sed filter script is rewritten by sed during rpmbuild to invoke the correct perl.req.
the filter script is applied only to the output of perl.req (which is normally only invoked by find-requires)
(As far as I can tell, perl.req predates explicitly listed dependencies in Makefile.PL and/or the META files. What it does is look for likely use and require directives in perl code with some logic and regex's, the implementation of which is exactly as attractive as you'd expect).
To be honest I'm not entirely sure in what circumstances perl.req and find-requires are or are not invoked (cursory testing by setting AutoReq didn't have an effect for me), but cpanspec reads and processes META.yml directly if found in any case. The only other dependency-related functionality is (rudimentary) processing of Makefile.PL to extract modules references in PREREQ_PM and add those as BuildRequires
Normally you can patch up your .spec file to add something like
%filter_from_requires /XSLoader/d
%filter_setup
However, :MODULE_COMPAT_xxx is a special-case dependency in cpanspec, you can turn it off with the -o option to create "compatible" RPMs that work on older systems. This has other effects too, so it might be less problematic to build in discrete steps so that you can tweak the build:
cpanspec [...] yourmodule
sed -i'.bak' '/^Requires.*:MODULE_COMPAT.*/d' yourmodule.spec
rpmbuild -ba yourmodule.spec
(especially since cpanspec warns that -b is not guaranteed to work always).
Of course the final package may not work as expected, cpanspec is being cautious, but there might be a real API requirement for this constraint (in your case the "noarch" build may limit the scope for problems, I think). The rule of thumb is that API/ABI's try to be backward compatible, not forward compatible (a related problem occurs if you try to build binaries to work with a glibc older than the one you compile against).
You may have better luck building on a CentOS 5 system (or investigate Mock for a more complete solution).
I'm trying to go through the Software Foundations Coq book (http://www.cis.upenn.edu/~bcpierce/sf/current/toc.html), but when I compile Induction.v (which looks like http://www.cs.uml.edu/~rhenniga/coq/sf_induction.html), I get the error message "Error: The reference evenb was not found in the current environment." -- even after compilation of Basics.v. Any ideas why?
I can confirm that opening CoqIDE from the same directory works on macOS: cd <sf-dir>; /Applications/CoqIDE_8.5.app/Contents/MacOS/coqide
from: The reference "X" was not found in the current environment
Try to erase every blank character in the address related to Coq or software-foundation book.
In my case, when I struggled with the file
C:\Users\XxX\Documents\software foundation\lf\Induction.v
, CoqIDE failed to execute From LF Require Export Basics and to define evenb_S theorem. Also, I couldn't see any files like Basics.vo or Basics.glob created when Basics.v with [Compile] - [Compile buffer] function in CoqIDE.
Everything works fine when I change my folder name to
C:\Users\XxX\Documents\softwarefoundation\lf\Basic.v
The Coq installer had already informed this >>
Link to the screenshot image of Coq setup
Compiling Basic.v with coqc Basics.v command should produce Basic.vo and Basic.glob files in the same directory. Then you should be fine with compiling Induction.v in the same directory as well; coqc Induction.v.